Historic:ProposedSolutionForTheCommunityPoll

This is just a proposal, a starting place. It is meant to be amended as needed. IF you wish to amend it, put a comment at the end of this page with your name (and maybe a number) as a proposed amendment, in the form: change OLD TEXT to NEWTEXT. This way we can discuss the 'audioguy amendment 1' etc. and even vote on them if needed.

The problem roughly divides into two parts, which I think of as the 'Social Part' and the 'Technical Part' so these are dealt with separately.

The Social Part

• We need to have peoples permission to email them for the voting. That permission will be obtained in this fashion:
  • On Monday,SOMEDATE,UTC a notice on Soylent will go out that on Thursday,SOMEDATE,UTC a copy of the user database will be dumped.
  • Anyone who has You/Preferences/Messages/DailyHeadlines set to to 'E-mail' at that time will be considered to have registered to vote and given their permission for us to email them ballots.
  • Anyone who does NOT wish to participate should make sure their You/Preferences/Messages/DailyHeadlines is NOT set to E-mail on Thursday,SOMEDATE,UTC. After Thursday,SOMEDATE,UTC the preference can be set back to whatever is desired.

• A normal internal staff poll will be held for the name.
• The results of this poll will not be made public yet.
• The top five names in that poll will be reserved.
• The first stage community poll will go out (asking for submissions of names)
  • What goes out as the proposed choice fo this purpose will simply be the existing name
• These names are collected, and the first poll is done on this list (which may be quite long)
• The results of that poll will be totaled, and the top five choices determined.
• The submitters of those top five choices will be contacted, and asked to provide a note promising to allow us to use the name.
• If the submitters have not already done so, we will reserve those names.
• The runoff poll will now go out to the community, but this time will include the top five choices of staff, and the top five choices of the community. (all already reserved by this point)
• At this point, the staff will have a second full vote on the same ten items the community voted on.
• The result of this vote, and the community vote, including its runoff, will then be published.
• The staff vote is the final decision. We have to live with this. But it is expected the community will have a powerful influence on the final staff vote.

The Technical Part

• The existing staff poll code will be forked and installed under a new user, after at least one full test of the staff system is completed, to find any problems with the existing code.
• The database dump referred to earlier can be created from a simple script that selects the needed fields from the main db, and copies that over to the staff server for use.
• The system will, using that db, create an md5sum of the username, userid, useremail, passwordhash, and the specific poll id used (the one identified on the staff poll setup page as 'Poll Identifier'). This creates a unique user id that is non sequential, hard to guess, unique to each user, and unique to each poll.
• Code will be added to add the ability for the poll system to send each user a unique email (with their identifier, the md5sum mentioned above). I have code already which can be modified slightly for this purpose. It just reads through the database send each email with its special id, taking the addreses and ids from the database.
• On the receiving end, procmail can be used to extract the user identifier from each email. Each email can then be saved under that identifier. This will prevent people from voting twice - each time an email is received it will overwrite any previous emails, so only the last will count. (All emails will also be copied elsewhere so they can be checked for cheaters later, if desired)
• A check will be added so that any duplicates WITHIN the same email will also be dropped.
• a check will be added so that emails sent for the wrong phase will be dropped. (procmail)
• The code will be more heavily armored against badly formatted emails (am already testing this).
• The regex will be tightened up to match specifically domain names for this particular poll. These follow a regular, predictable format.
• It is suggested that the names people submit all be under the .com first level domain, this will help remove dups. Alternately, this could be done in the code by strippimg off the endings. This would preclude the submission of 'cute' names like 'news.foryouand.me'
• The totalling etc should be pretty usable as is.
• Step '4. Send the first real poll out' will need to be split into two steps for the public poll. Currently it automatically grabs all the submitted poll questions, sorts and selects them, and immediately sends them out as the first poll. This is fine for small staff polls, but could be a disaster for polls with possibly hundreds or thousands of items. We need a break to do a quick manual check, 'just in case' so our computer does not send out 3000 'mistakes'. ;-)

Proposed Amendments, Changes

(put your proposed changes here)

Final Finished Plan

(To be filled in...)