After several early attempts, we have settled on a process for deciding on the final name for this site currently known as SoylentNews.org. You'll need to log in and go to: userprefs/homepage and check the box marked "Willing to Vote" if you'd like to participate (do this now, the submission round will go out soon). The vote will occur using an email-based solution loosely based on the Debian/Condercet method that we cooked up. Note: checking this box will indicate that we are scraping your email address from the database for participation (this is completely opt-in). If you wish not to participate, just make sure this box is unchecked (this is the default).
We are opening the floor to name suggestions. If you have suggested a name earlier, you'll need to re-submit it through this email voting system. Though we prefer available domains, if you have pre-purchased a domain (eg: to prevent squatters), by submitting the name you are stating that you are the owner of the domain(s) and will give it without strings attached to this project if it were to be chosen.
The criteria for an acceptable name:
This is how it will work:
If you're interested:
NCommander adds: So its finally here, and I wanted to apologize for the long delay before this actually happened. To the editoral team, please bump this to the top of the index for the next 24 hours so everyone gets a chance to see it (click 'fastforward' then save to autoupdate the timestamp). I promise a Featured Story option is coming in the next major update so we don't have to deal with this!
There have been a lot of questions about how this works and why we did certain things. I will try to answer them togther, in the next two posts.
Most of the questions that start with this have one of two possible answers.
1. 'Because we don't have a clue how to do that.'
This is mostly the questions about why we didn't just do a poll in slash code. Covered in the next post.
2. 'Because there was not enough time to do that.'
These are in reference to a lot of great ideas, that we just did not have time to implement.
Covered in the post after.
Unless you are interested in a lot of really boring details you can just stop reading here. :-)
'Because we don't have a clue how to do that.'
This site was started by a small group of volunteers who used open source Slash code to start a site as an alternative to some corporate actions we felt were unacceptable.
The code we are using, slash code was written years ago, by a pretty good perl programmer who was very knowlegeable about all the various perl libraries and fairly sophisticated techniques. But a young programmer, who by his own admission (I am slamming no one here) made a few mistakes. In addition, the code has been hacked on by others at a later date by others, perhaps with a slightly different vision. The net effect of this is code that is very confusing to understand and work with.
There is NO ONE on staff here who had anything to do with the writing of this code. It is completely new to everyone. In addition, our perl programming expertise is pretty limited, there are just one or two people who might be called accomplished, and I do not believe any that have written an application the scale of slash code. (Maybe one, not sure). It doesn't really matter, as even a really sharp perl expert is going to take a while to get up to speed on THIS code.
It might be descibed as that famous 'maze of twisty little passages'. Or at times, it reminds me of those old 'home improvement' comedy sketches Red Skelton used to do - you know, where you turn on the water and the radio starts playing, to turn on the closet light, you must flush the toilet.
There are a lot of interactions, sometimes the simplest of things is REALLY difficult, and occasionally the reverse is true.
To answer one question, and provide an example: 'Why didn't you have the sidebar status up from the start?'.
Answer - because we had never done that before, and it took a while to figure out how to do it at all. And when we did, initially, the only way to update that little text box was: to do a complete re-install of slash code.
That's right, read that again: 'To update text box, do complete re-install of slash code.'
We have a better way now, but that REALLY was the case initially. We are learning the code, it just takes a while.
So, 'Why didn't you just use the slash poll, and limit it to registered users, and modify it to handle more names' etc.
Because it would have taken a long time to sort all that code out, write new code, and make sure we weren't causing the toilet to flush every time someone voted. :-)
We just didn't feel we had the time to do that properly.
We are learning the code, and making improvements, but at this stage, every one is very hard won.
Or, 'how the shit actually came down'.
I apologise for the length of this, I have not had time to write a shorter one.
The code being used was not originally written to handle the name vote.
Originally, it was written to solve a staff problem:
We have people all over the world, and what was happening is that a group in a similar time zone would get together, identify some issue, solve it, and vote on the best solution. The problem was that 12 hours later another group, or person, would then say, 'wait a minute, we didn't get to vote on that, and by the way, would have suggested a different solution, 'Z', because we know about X and you did not take that into consideration. And this was not just grousing, often they were absolutely correct.
So we needed to come up with a solution to this, some kind of voting system that could spread the vote over a day or more, and, incidentally, it would be nice if it could also have a way for people to ADD OPTIONS to solve -that- problem.
We set up a group to look into possible solutions, which they were doing thoroughly. But that takes some time, so it was decided to write a quick, temporary solution, until that work came to fruition. I got the job.
Email was chosen because of its flexibility, and in general, I tried to take as flexible approach as possible. Who knew what this might be used for? Parsing emails is hard, because of dozens of different email programs, each with its own quirks, and in some cases, bugs, but this was for a very small group, mostly having sane email programs.
Knowing that, I figured I could get away with fairly simple tagging, because while something like having start and end tags such as html uses is much easier for a program to parse, it is very painful to look at.
So the simple '[n](nn) item' was chosen.
Why [1-9] ? Well, the original idea was really to have NO rigidly enforced system. Using just one number helps make the lines a bit easier to parse, and allows for multiple uses, for example, 1-9 could be used for ranking, but in other cases a binary option like 0/1 could be used, or other variants.
The (nn) was just because some way is needed to keep track of the items reliably, with less worry about a small change in the text of the item itself causing it to be missed. Something that happens a LOT in emails. Even plain text emails are not completely safe.
Provisions against cheating? Dupes? Etc.? None. This was staff, not worried about that at all.
Plans to adapt this to the name vote? None, originally. At best, I thought we might learn some useful things that might help with whatever we used for that later.
But the code was designed to allow each vote to have three phases, 'item contributions', 'initial ranking or voting', and a 'runoff vote' if needed. So it would solve our problem.
The code was written in a day. Then two days were spent creating a web based user interface so any staff member could initiate and run a poll or vote. (user interfaces, the bane of a programmers life)
Done. Not great, but good enough until we got something better.
-then everything changed-
There was a LOT of pressure to have the name vote as soon as possible, for a number of reasons, including keeping a promise, and the fact that this was keeping us from completing our incorporation (you need a name...).
We needed something fast, and something that one of our own staff could modify, if needed.
And it just so happpened we had something that could, sort of, do what was needed. That could accept submisssions, and handle ranking, and runoff votes. But had no way to interface to a database, and no protections against cheating, and so on.
So some changes would have to be made, and quickly. Those changes were made in about a day and a half. One, single test was then run with about six staff.
The next event that code handled was the real name vote. Which is what we are in now.
-- So: answers... --
-- Why plain text? Why not just the convenience of 'anythng goes'? --
Because I am not a good enough programmer to write code that can handle every one of literally thousands of different mail programs, variations of those, and bugs, and the outright violations of the RFCs some of these programs contain. And even if I had been, there would have not been enough time to test them all, even once.
So I made a 'best effort' to try to decode as many as possible, and then asked people to use plain text, which almost always works. The best effort is for those absolutely stuck, as some are. And in the end, if it really cannot be deciphered, it can be manually counted. (and will be)
The restrictions people complain about are really there just to try to give your vote the best possible chance of being decoded properly.
-- Why is there no feedback email? --
Because of the very short time period, and the high probability of problems in some very untested code, I decided to program VERY defensively, saving all intermediate steps, and NOT trying to decode or tally emails 'on the fly'. I let the mail server, a program written and tested to do that well, deliver the mail. Only later is the mail processed, which means I can't lose any emails, and can repeat the process, if needed, to fix a bug.
A side effect of this is that there is really very little information available while delivery is taking place. If the tallying was being done, I could keep track of that state and send back an error message if something was wrong. But with nothing like that being done, the best an email sent back could say would be 'your email was delivered'. That is information already apparent however - we are not filtering email like an isp might. If your email is NOT deliverable, you WILL get an error back immediately from the mail server (as a few have unfortunately found out from Yahoo.)
There are also certain precautions one must take with autoresponders, it is not quite as simple as you might expect. The long and short of it is that it was something I did not feel I could spend the time on for a very limited utility.
-- Why Email? --
#1 - It was what we had ready, and handy.
2. We could send people tokens to help prevent cheating fairly easily.3. It was free form enough to allow for name submissions easily.4. It should be fairly easy to repurpose.
Mostly, in all honesty, #1. :-)
-- Why are the numbers setup so your first choice gets a nine and your least choice gets a 1? --
Well, there are two ways of thinking about this. One is that you are ranking or scoring items, the other is that you are making choices 'first choice' 'second choice' etc. I did not know which was 'more intuitive', since this was not a one time winner takes all vote like US elections, but rather a scoring system. It was not necessarily clear one was more intuitive than the other. My time for researching this was also limited, but I had to make a choice fairly quickly. Whichever I chose, it seemed lilely some people would feel the other was was more intuitive.
So looked at other things.
What the program actually does is add these. So it seems better to let the user choices also reflect this directly.
Another factor was that (going back to the staff version), this way allowed me to have a zero, if I ever needed one, while still having the easier to parse single numbers in brackets.
For better or for worse, that is how this was decided. In about 2 minutes. :-)
-- Why not vote for just one, like US elections? --
Because this is a little different situtation, where a second choice can be important. What we really want is the best possible choice, not to 'keep the evil guy on the other side out'.
Remember anyone could submit a name, so presumably would vote for their own.
It's too much to go into here, but ranking tends to pick choices that are the best compromises (= less pissed off people). Do a google search on 'voting algorithm' and have fun.
-- What voting algorithm are you using? --
Heh. Very fancy name, that.
What it actually is, is a very loose attempt to come up with a 'Condorcet winner' by ranking, and having two rounds, coupled with the practical requirement here that we may have to drop down to 'next best choices' if for some reason we cannot get control of one or more domains.
In other words, we just add the scores and highest scores win, then have a runoff. And pray we don't have a tie. :-)
The staff vote, and ultimately NCommander, can break a tie.
The whole vote process is on the wiki. http://wiki.soylentnews.org/wiki/ProposedSolutionF orTheCommunityPoll [soylentnews.org]
-- Why can we only use each number once? --
This is an attempt to force people to actually make choices based upon preference ranking, rather then just an easy '9 for all my favorites'.
The hope is that it will provide less chance of a tie as well.
-- So if your second choice was given an '8', does that carry more weight than if you gave it a '5'? --
Yes, that is the whole point. Vote your relative preferences.
-- Why was the list so long? Why not just shorten it? --
Tough question. Who gets to decide? And take the brickbats from those unilaterally removed?
Don't look at me.
The whole issue was tough, because we simply did not know what to expect. You can see my own vaccillation here pretty clearly - At first I was terrified we would get a 4,000 name long list. Then that we would only get a few.
In the end, we had about 90 and I think that was long, but workable. And all names submitted got into the list, as far as I am aware.
-- It could have all been done better --
No doubt about that. It's our first time, and we had a very limited time frame. Nobody was under any illusions there would not be problems.
Thanks for making the best of a difficult situttion.
We hope to do better next time.
Thanks for all your effort on the voting system, and also for your summary of the behind-the-scenes action.Much appreciated!
The answer to this is purely practical.
Since we were using email to send ballots, we had a problem: you cannot just send emails without peoples permission.
At one point, the checkbox for getting the daily summaries that registered users can get was set by default. A number of people took exception to this, some even claiming we were spamming them. (This was unintentional on our part, slashcode came with that set by default)
So that was fixed, but it made us very aware of the sensitivity of our community on this issue.
Anything that required an email ballot would therefore need peoples explicit permission. We tried several approaches, things like adding special tags in various places, but all were pretty awkward. In the end, NCommander was able to add a checkbox and field to the database specifically for this purpose.
But there is another problem, which is that sending bulk mail, which this certainly would be, can get you into major block lists. All it takes is one or two complaints, in some cases. To get OUT of these blocklists, you must be able to PROVE :
1. That users explicitly signed up.2. That the signup mechanism did NOT default to on, in other words, they had to actively take an action to sign up.
We used a checkbox with the idea that people could sign up for votes they wanted to participate in, and not for others. So that checkbox is easily changed at any time.
Yet, we needed to be able to prove a user had signed up for a specific vote.
The only way we could do that is to dump that choice out, at a certain point in time, so that we could show that yes, THIS user signed up for THIS specific vote on THIS date.
This is why, for each vote, there is an explicit sign up period (which we call registration, since the term is familiar), and an explicit cutoff date.