Historic:ProposedSolutionForTheCommunityPoll

Obsolete Page

This page is obsolete and only retained for archival purposes.

CommunicationSystems - parent

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 for 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 sends 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). This approach has the side benefit that it allows people who change their mind to do so, provided they do so before the votes are totaled.
• 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 (I 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', however.
• 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'. ;-)

Stuff requiring others help to make this happen

• Everyone needs to be signed up for the staff poll so that final testing can be done.
• It would be nice if we could use a virtual subdomain for this (easy for the users to remember). Needs to go into domain name. (I need to look up what was decided abou this earlier)
• If someone who is more up to date in their knowledge of mysql/sql could help with the database query, it would be faster than I could do it. (needs data from two tables, and one field may be a bitfield we need to extract a value from)
• The modifications to the vote sytem will need to be tested. Fortunately all the staff is also registered on the main site, so this can be done with this subset of users. Will need people to participate in a test poll or two.

Proposed Amendments, Changes

(put your proposed changes here)

• After reading the editors discussion in staff list, I am feeling my original permission plan is flawed. This probably needs to be something that requires an active step by the user - the problem with the Daily headlines idea is that it is on by default. Looking at other possibilities.

• Attempt to use a tag in sig field aborted...
• NCommander added a checkbox to main site for this, yeah! Problem solved.

Final Finished Plan

The Social Part (final)

• We need to have peoples permission to email them for the voting. That permission will be obtained in this fashion:
• A new checkbox has been created in the users section of the main site, called 'Willing to Vote'
• Users checking this box are indicating they wish to participate in the next vote, and giving us permission to email them the voting forms at the email address they used so sign up for the site.
  • 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/Homepage/'Willing to Vote' checked 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 this checkbox is unchecked. (It is off by default).
• 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 for 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 time frames for each step will be three days plus a possible buffer day per step.
• The staff vote can happen at the same time as the community votes, these do not have to be sequential.