Editing Maemo.org team/How Elections Work

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

This page details the current [http://maemo.org/vote voting system] and how it works.  It is presented as a means of offering transparency into how voting is handled and how the current system provides both anonymity and verifiability in community elections and referendums.

= Overview =

The voting system provides voters with a multiple-choice interface which can be used to create an ordered list of selected options.  Voters can select some, none, or all of the choices, and order those choices as they prefer them.

For multi-seat elections, voters may choose any number of candidates, be that greater than, equal to, or less than the number of seats (see Single Transferable Vote below). For the special case of a two-choice referendum, voters should be aware that there is no (additional) sense in choosing both options, though the voting system may in fact allow them to do so. ''Only the first selection in a 2 option election will be counted.''

Voters that dislike the choices, or want a choice not presented, may show their desire to participate by choosing nothing and casting an empty ballot. If enough voters cast empty ballots it can affect an election by making fewer (or no) candidates reach the required "quorum" levels to be elected.

= Parts of an Election =

The current voting process is divided into several pieces.  Some of these are not visible to the voter, or are taken as a given.  To ease the process of explaining the process, we will follow the "life" of a single vote, from the creation of the election to the final results.

== Elections ==

Elections are created by an administrator (often Council) and stored in the database with several vital fields about that election.  Included are the start and stop times, the title of the election, text about the election, candidates for the election, and the number of "winners".  The contents of these tables generally show up in one form or another in the interface for voters.

== Electorate ==

The system also contains an electorate list; the list of ''users eligible to vote'' in an election.  That list generally gets updated from the main maemo.org list before elections are started. The date this happens is the relevant date for calculating karma, account age, and so on. Only users that meet the conditions ''at that date'' are included to the electorate table.  It is '''difficult''' (but not impossible) to update or adjust this list after elections have started.  To avoid complexity it is asked that voters check their account settings, '''particularly their email address,''' and setup any linkages needed at least a few weeks before elections start.

== Voting Tokens ==

When an election is setup and ready to be used, and the electorate is verified, an administrator instructs the system to create and mail tokens for the electorate.  A script in the system then generates a random voting token for every member of the electorate, and mails that token to each voter.  The voting token, used as a password for the voting login screen, is valid for one vote in the election for a given voter.  Administrators never see these tokens (aside from any token they may get as a voter).

The tokens are stored in a separate table, with a numeric pointer to the voter and election for which it is to be used.  Storing them this way, in separate tables, makes it harder for an administrator to "accidentally" see a voter's e-mail and token together if they need to look at the database for any reason.  The odds of anyone guessing a token is also quite slim, and both the token and e-mail address is required to log in to vote.

== Voting Process ==

The entire voting process is state driven.  When a voter chooses an election and logs in, the system validates the token to allow them into the voting interface.  This is a "courtesy validation" to allow the voter to know that the token is still valid.  Nothing is altered by this step.

The list of choices is presented to the voter, and stored in a ''javascript applet'' in the voters browser that allows the voter to chose as many options as they like, in the order they like (note that you can undo choices by clicking on the list of chosen items).  When the voter is happy with their choice(s) and proper order, they submit the choices for validation and confirmation.  The vote selection is validated, displayed to the voter to confirm that the system got their choice(s) and order correct, and the voter is asked to submit the vote for final processing.

The next step is the most complex and critical.  Once the vote has been submitted, several things happen all in one single action:
# A random vote validation string is created for this vote.
# The vote is prepared for entry into the list of votes with this random string.
# The system atomically (as one step):
## Validates that the vote token is still valid
## Adds the vote to the list of votes
## Deletes the valid vote token

At this stage, one of two things happens:
* If an error occurs, all sub-steps are undone, leaving a valid vote token, and an error is reported to the voter.
* If all works as expected, the random vote validation string is presented to the voter.

Lets look at those sub-steps a little closer:

The first sub-step generates a random validation string for your vote.  When the vote is stored in the vote table, that is the *only* reference as to "who" cast this vote.  Being that it's random, the only way one can know it is by seeing it on their screen, just after submitting their vote.  This is important because '''it allows each voter to validate the public ballot later''' by looking up their unique entry to verify their vote was counted as they cast it.

The third step guarantees that a voter always has either a vote token, or has a vote cast with a random validation string.  This prevents multiple votes per voter, and prevents technical problems from leaving a voter stranded without a vote.  For this reason, '''at any time up to the point one hits the "submit vote" button on the validation page, and gets a validation token random string displayed, one may close their browser, or hit back, to change their choices, or start all over anew with the process.'''

== Post Election Ballot Validation ==

Once the vote has closed, the ballot of all votes cast is ''publicly'' viewable (and downloadable) by everyone.  The list includes the votes cast, including the order of the choices for multi-choice votes, and the random validation strings for each vote.  Since each voter knows his or her validation string, they can validate their vote is correct.  They can also count the votes, and validate that the ''results'' of the election are correct.  But since only one random validation string is known per voter, voters (as well as admins) can not determine who voted for which candidates in the election.  Since there are no links to the original owner or starting token in the final voting table, there's also no way for an administrator (or anyone with database access) to determine who voted for which candidates either.

= Technical Details =

This area is for a more technical look at how things work, and may be less interesting for the general voter.

== Source Code ==

For those interested, the voting code is public domain and can be reviewed.  At this point, the entire voting system consists of PHP code, a small piece of javascript that runs in the browser, and a perl script that handles e-mail delivery.  Since the addition of the admin interface, even the administration functions are now in PHP.  The OpenSTV portion is written in perl, and is also opensource, though there is a requested donation (which has been made on behalf of Maemo for our use of it).

== Database Setup ==

The database schema for the voting database is also checked in as an SQL script that can be used to create all tables needed for the scripts to function.  Any updates to tables should be included in this schema.

=== Individual Tables ===

There are several tables in the election interface.  Below is a brief description of each, as they exist at the time of writing this wiki page.

{| class="wikitable"
|-
! Table Name
! Description
|-
| admin_users
| This table contains the information needed to validate users of the administration interface.
|-
| elections
| This contains a list of all elections, past, present, and future.
|-
| election_anon_tokens
| This contains a list of all validation strings ever made, and indicates which election the token was made for, but not which voter.
|-
| election_choices
| This contains the choices for all elections, from Yes/No to candidates for elections.
|-
| election_results
| This contains html blobs that are shown as official election results.
|-
| election_tmp_tokens
| This contains the list of all tokens for all elections.  Each token knows which voter and election it belongs to (via numeric index).
|-
| election_votes
| This contains the actual votes for an election.  The only references here are to election_anon_tokens, to indicate which votes go to which verification string.
|-
| electorate
| This contains the list of all eligible voters for all elections.
|-
| midgard_users
| This is a temporary table, imported from Midgard and/or the garage to allow scripts to update the electorate in an easier fashion. Creation date of this table determines the karma, account age etc used to decide eligibility of a user.
|-
| outbound_email
| This system handles queuing and batching mail to prevent us from looking like spammers. Temporary table. Depletes as mails get sent out.
|}

== Cloning Voting Tokens ==

One option available for administrators is to "clone" voting tokens from one election into another.  This allows one "password" to be used in two or more elections.  This process is often desirable when two elections are happening at the same time or in close succession, as it cuts down on the number of tokens mailed out, and eliminates confusion about which voting token string to use for a given election.

For example, the Coding Competitions often have 5 to 10 categories, each with a separate election.   Having 5 to 10 tokens mailed to voters could cause spam triggers, and/or could confuse voters as to which token to use for which category.  Instead, one token is created, and cloned to the other categories.  The allows a voter to use the same e-mail and password to vote in all Coding Competition elections, but still only allows one vote per voter per category.

Cloning works because each token has a reference to the voter and election for which it exists.  When a token is cloned a '''copy''' is made with a ''different'' election identifier.  This means two tokens exist with the same random "string", but each points to the same user and a ''different'' election.  When a voter casts a vote in one election, just the token for that election gets destroyed.

This is also the reason tokens can't be cloned after voting has opened on an election.  Since voting tokens are destroyed as the vote is cast, cloning from an active election would mean those who already voted in the election would not have a token to copy, and thus would not be able to vote in the cloned election.

{| class="wikitable" border=1
|-
!
! align="center"| Voting Tokens
! align="center"|           Votes & Verify Strings                
|-
! Setup Referendum 1 
|
 '''(3UA9VTp,Alice,Ref1)''' 
 '''(oUB3VTq,Bob,Ref1)'''
 '''(yUC9VTr,Chad,Ref1)'''
 ... [all eligible electorate]  
| 
|-
! Clone Referendum 1 to Election 2 
|
 (3UA9VTp,Alice,Ref1)
 (oUB3VTq,Bob,Ref1) 
 (yUC9VTr,Chad,Ref1)
 ... 
 '''(3UA9VTp,Alice,Elect2)''' 
 '''(oUB3VTq,Bob,Elect2)'''
 '''(yUC9VTr,Chad,Elect2)''' 
 ... 
|
|-
! Alice & Chad Vote In Referendum 1 
|
 <strike>(3UA9VTp,Alice,Ref1)</strike>
 (oUB3VTq,Bob,Ref1)
 <strike>(yUC9VTr,Chad,Ref1)</strike>
 ... 
 (3UA9VTp,Alice,Elect2) 
 (oUB3VTq,Bob,Elect2)
 (yUC9VTr,Chad,Elect2)
 ... 
|
 '''"Yes" &rArr; OMGuVotedN0wg0prty (Ref1)'''
 '''"No" &rArr; Yualw4ysSoN3gatlve (Ref1)'''
|-
! Alice & Bob Vote In Election 2 
|
 (oUB3VTq,Bob,Ref1) 
 ...
 (wUZ3VT5,Zarrah,Ref1)
 <strike>(3UA9VTp,Alice,Elect2)</strike> 
 <strike>(oUB3VTq,Bob,Elect2)</strike> 
 (yUC9VTr,Chad,Elect2)
 ...
|
 "Yes" &rArr; OMGuVotedN0wg0prty (Ref1)
 "No"  &rArr; Yualw4ysSoN3gatlve (Ref1)
 '''"Kyle","Lucy" &rArr; M4nUVote4YurBudzEh (Elect2)'''
 '''"Jim","Mandy" &rArr; OMGuVotedTo0g0prty (Elect2)'''
|}

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "https://wiki.maemo.org/Maemo.org_team/How_Elections_Work"

Personal tools

Navigation

Views

Editing Maemo.org team/How Elections Work

@@ Line 92: / Line 92: @@
 |-
 | election_tmp_tokens
-| This contains the list of all tokens for all elections.  Each token knows which voter and election it belongs to (via numeric index). Obsolete tokens (for elections that are closed) shall get deleted from this table.
+| This contains the list of all tokens for all elections.  Each token knows which voter and election it belongs to (via numeric index).
 |-
 | election_votes