please test PEAR's brand-new election interface

Hi all, This is a long post, so I've broken it into summary and detail. Summary: ======== I would like you all to test the new election interface. Just log in as your PEAR account, and browse to http://pear.php.net/election.php. If you don't have a PEAR developer account (PEPr-based accounts won't work), request a new account for voting in general PHP elections through http://pear.php.net/account-request-voter.php Detail: ======= As you may recall, not too long ago there was a lot of talk about moving PEAR in a new direction, which died down after the initial spat of ideas. At the time, I was stressing the need to move the PEAR website in a new direction prior to attempting to do anything drastic with PEAR as a whole. One of the immediate concerns I had was how to even determine where PEAR's users want to go? The QA team "elections" through PEPr have turned out to be rather ineffective, and attempting to resolve things through the mailing list is - well, let's not go there. Suffice it to say that we used to vote for packages on the mailing list prior to the coding of PEPr and that was a complete disaster. Clearly, we need some kind of way to poll the users to get a definitive answer of what is wanted, otherwise it will never be possible to make any large changes in PEAR due to infinite debate and finite patience. As such, I have spent the past two weeks or so devising a systemized way of administering and managing elections in PEAR. Unlike PEPr, only registered developers with "pear.election" karma can create or edit elections (with the exception of admins, of course), and more importantly, unlike PEPr, these elections are secret ballot. The election code can support elections for a single outcome or elections with many possible choices. Examples of hypothetical single outcome elections: - voting for the leader of PEAR - voting for which bug tracker to use Examples of hypothetical multiple outcome elections: - voting for 5 members of the QA group from a list of 13 candidates - voting for 5 important points for the mission statement out of 13 bazillion The sample elections at http://pear.php.net/election.php demonstrate both kinds of elections. Please vote to try it out. I want to know any usability issues as well as bugs that you find. One other important feature is the ability to register displeasure with the entire election by choosing "abstain." This important feature will allow us to determine whether an election is bogus (no choices worth voting for) as well as monitor developer interest in an issue. The single most important feature is the ability to craft elections for different voting publics. Elections for PEAR leaders, for instance, should be open only to PEAR developers. Referendums on which bug tracker to use, however, should also be open to the end-users of PEAR packages who will be the ones using the tracker to report bugs, as well as the developers who will be fixing the bugs. Both of the sample elections are open to the general PHP public. This can be controlled per-election. If the need for another kind of voter public sub-group needs to be created, this can easily be accomplished programmatically, the database will support up to 127 voter sub-groups. God help us if we even *approach* that level of complexity :). 2 should be enough for any election scenario I can envision. Technical detail: ================= How does the secret ballot work? The secret ballot works through two separate database tables. One records whether a particular handle has voted in an election, to prevent voter fraud, and the other records the actual votes. Each vote is recorded in a separate row, and is recorded with a "vote hash." This hash is an md5() of the voter's handle along with a special "salt" that is displayed at the time the voter finishes voting, and is not stored or saved. The salt is the date and time of voting plus a random number between 1-1000. This means that in order to hack the vote of a voter, one needs to know their handle (easy), the exact time they voted, and then try all 1000 possible random numbers. For an election period of one week, this means worst case trying 604 million possible salts, and in the likely case (knowing the exact day that the vote was cast) some 84 million possibilities. Even if you know the exact hour that a vote was cast, there are 3.6 million possibilities to try, and knowing the exact minute still yields about 120,000, making it unlikely to be worth the effort when you can just email the developer and ask what they voted for :). The use of the hash also allows voters to check their vote after casting it, to make sure it was recorded properly in the database. This can be used in close elections to check your own vote to make sure it is what you meant it to be, or where there some question of manipulation of the database or more benign technical issues like bugs in the voting software. Performance considerations? Upon completion of a voting period, a cron job is run that calculates the number of votes for each choice and the number of abstaining voters, and it stores this along with percentages in a table that is used for displaying election results. This makes queries to calculate winners quite efficient even with large voter turnout. Political detail: ================= How do we decide what elections will be created? Which elections will be put to the voting public will initially be decided and also constructed by me, and I hope that one of them will in fact be a referendum on some sort of "constitution" for PEAR that will lead to an election for a leader(s) who will then decide what needs to have an election. Why do we need this? I don't feel comfortable foisting my own personal viewpoint on PEAR when it comes to important issues like the structure of governance inside PEAR. This has proven to be an ineffective governing strategy in PEAR's past, leading to inactive leaders, disillusioned developers and lots of annoying decrees from above. We have a unique opportunity to lead with intelligence, drawing upon the needs and desires of the people who use PEAR and the people who develop PEAR in a clear and systematic way. The election interface will give us a real mandate for changing PEAR, or at the very least clarify the debate on issues. Please test the interface so we can start using it. Thanks, Greg