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!
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!