Historic:ProposedSolutionForTheCommunityPoll: Difference between revisions

From SoylentNews
Jump to navigation Jump to search
No edit summary
No edit summary
Line 12: Line 12:
* The results of this poll will not be made public yet.
* The results of this poll will not be made public yet.
* The top five names in that poll will be reserved.
* The top five names in that poll will be reserved.
* The first stage community poll will go out (asking for submissions of names)
* 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
** 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)
* 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 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.
* The submitters of those top five choices will be contacted, and asked to provide a note promising to allow us to use the name.
Line 22: Line 22:
* The result of this vote, and the community vote, including its runoff, will then be published.
* 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 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 Technical Part ==
Line 32: Line 31:
* A check will be added so that any duplicates WITHIN the same email will also be dropped.  
* 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)
* 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 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.
* 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.
* 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.
Line 41: Line 40:


* Everyone needs to be signed up for the staff poll so that final testing can be done.
* 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 as 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)
* 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.
* 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.
* 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.



Revision as of 18:54, 30 March 2014

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)


Final Finished Plan

(To be filled in...)