Meeting:2012 AGM/Election Administrator's report
Draft Copy - 21:56, 26 November 2012 (EST)'
The 2012 Wikimedia Australia (WMAU) was run between 16 November 2012 and 23 November 2012, with the results announced at the Annual General Meeting (AGM) of 25 November. The returning officer was Steven Clark, and the election System Administrator was myself, Adam Jenkins. The election was run electronically using online voting, using software that I had written to manage online voting using the Single Transferable Vote (STV) model, with Optional Preferential voting.
Pre-election and preperation
The software that was used for the election has been previously employed to run other online voting requirements unrelated to Wikimedia. Therefore the software was already written and tested prior to the 2012 WMAU election, and no changes to the core functions were required. As the software was previously under consideration for use by WMAU in the 2011 election, the core source code has been available on the WMAU wiki since late 2011, and a working test version was provided for the 2010/2011 committee.
In 2012 I was contacted by the WMAU committee and asked if the software could be provided for their consideration for the 2012 election. I was also asked to provide the non-core code and the SQL for public access on the wiki. Accordingly, the WMAU public wiki was updated with all of the information required to install the software on 15 October 2012, and a new working test install was provided for the committee.
On 22 October 2012, John Vandenberg, the President of Wikimedia Australia, informed the members over the private members mailing list that the election would be held on 25 November, and that two software packages were under consideration – the software that I wrote and is discussed here, and MemberDB. The membership was informed that the decision would depend on community feedback.
Subsequently I was informed that the software would be used for the election. John installed the software on the Wikimedia Australia server and then, prior to the start of the election, provided me with access to the server and removed his own access, ensuring that no committee member could access the WMAU server during the election period. I then independently verified that the software was correctly installed, that the code was as written, and that the database was correctly configured. As part of this I created an account for myself, gave myself administrator access, and then deleted my account once I was sure that everything worked.
I then informed the Returning Officer, Steven Clark, that it was good to go, and we discussed my role in the election. As I wrote the software, we felt that it would be better if I retained access to the server in case something went wrong. However, to ensure that things remained transparent and above board, I agreed not to access the server except in the presence of the Returning Officer once the election began, and the Returning Officer would be able to check the access logs if required to make sure that everything was ok. As I had access to the server, we agreed that I would not vote, and I chose not to express any opinions about the candidates during the running of the election. It was also agreed that I would not have administrator access to the election software, so I would not be able to view the progress of the election. That access was exclusively limited to the Returning Officer.
The Returning Officer then created an account with the election software which I configured to have administrator access. He confirmed that things were fine from his end, and informed the Secretary, Charles Gregory, that the members could be told that the election was now open. However, email problems meant that the Secretary did not receive the Returning Officer's email, or my subsequent replies when the Secretary followed up to see if things were ready for his announcement. This meant that the Secretary remained unaware that the Returning Officer and I were ready for the election to start. I became aware that there was a problem with email when I received a message from the Secretary informing us that he would be unavailable for a period, and providing a copy of the official announcement to be forwarded to the members mailing list when things were ready to go. When I became aware of the problem, and noting that the Secretary was unavailable, I took it upon myself to send the message to the mailing list per the Secretary's instructions. Accordingly, although the election software was ready and running at the scheduled time, the official announcement to the mailing list was delayed by several hours.
Running of the election
On the whole, the software gave few problems during the running of the election. The only major issue to arise was when a member was unable to vote, as they did not receive the automatic email that is sent upon registering to vote by the software, and had been unable to complete their votes during the session that they were logged in. For security reasons, all passwords are encrypted in the database, and there is no currently installed method of sending a new password. (Due to the encryption method employed, it is not possible to decrypt the old passwords). The most reliable fix was to remove the unusable account from the system and allow the member to re-register. Per our agreement, this had to be done in the presence of the Returning Officer, causing a delay. Once fixed, the member was able to register and lodge their vote as per normal.
As part of addressing this problem, it was discovered that there was an error in the HTML, which meant that the email address of the Returning Officer was not being rendered correctly if someone tried to create a second account. This was easily corrected, and was handled in the presence of the Returning Officer at the same time as the first problem was corrected.
In addition, three minor issues were identified during the election:
- There is an unnecessary line break included in the automatic emails that will need to be corrected before it is next deployed.
- There was some confusion in regard to the use of Optional Preferential voting in conjunction with the Single Transferable Vote.
- The software needed to be manually closed at the end of the election period.
Otherwise, it appeared to have run as intended, with some improvements identified for future development. To date, there have been no reports of anyone being unable to register a vote over the course of the election, except for the problem raised above which was handled early in the election period.
The election was successfully closed at the allocated time, in the presence of the Returning Officer. After closing the election and disabling votes we did a quick scan of the Voters table to ensure that everything was as expected. The Returning Officer then left and completed the process without any further assistance, reporting the results at the AGM.
The system was designed to allow the Returning Officer to approve voters after checking them against the membership list, and, if needed, follow up with members to ensure that they did vote. However, while at no point is the Returning Officer given information about who cast which vote, from the database perspective it is, as is necessary with such systems, possible to derive this information. Accordingly, in preparation for the server to be returned to the control of the committee, and to ensure the anonymity of the voters, the Voters table was anonymised after a copy of the data was provided to myself and to the Returning Officer. Voters names, addresses and emails were removed from the database.
While it remains possible to do a recount at any time, it is not possible for someone other than myself or the Returning Officer to identify who made which vote, even with full access to the database, and we could only do so if we were given access to information contained in the database post handover. However, the Returning Officer remains able to investigate voting irregularities should issues be raised in the future.
During the running of the election I needed to access the server three times. The first was as described above, and was conducted in the presence of the Returning Officer. This required access to the election database and the election software. The second time the Returning Officer was not available, but access was conducted, with the Returning Officer's permission, under the supervision of Dr Donald Falconer from the University of South Australia. This did not require access to the election database and software, and was to remove a redirect to a non-functioning email address. The third access was to close the election, and was handled under the Returning Officer's supervision. The only other times the server was accessed were before the election's start, and after I was informed by the Returning Officer that counting had been completed.
Although the software ran well, given the problem with the lost email, a number of future improvements were identified. These could be readily implemented prior to the next election, if WMAU chooses to continue with the software. In particular:
- A method should be implemented for the Returning Officer to send a new password to a member, should their original password be lost.
- The ability to automatically start and end the election at set dates and time should be implemented. It should be noted that this would not have affected the start of the election, but would have streamlined the closure.
- A function to export and anonymise the voter data should be implemented. Again, this was not an issue this time around, but it would simplify the process if someone without sufficient knowledge of SQL was to run the system.
- The problem with the extra line breaks in the email header should be fixed.
A more comprehensive administrator front end should be developed for the creation and management of elections. This was not done previously, as the software was not intended to be used except by someone with the technical ability to set up and configure the system, but it would be helpful to have more of the process handled through a web-based interface. That said, it was advantageous to have a Returning Officer who had sufficient technical knowledge to ensure that everything was running as intended. It should also be noted that certain tasks, such as removing a voter from the database, should never be easy to do in order to prevent accidental occurrences.
Due to the concerns raised about how Optional Preferences fitted into the Single Transferable Vote system, additional user documentation should be provided to ensure full transparency. This is likely to be the case in the future irrespective of what package or methodology is employed.
It is recommended that members be surveyed about the software, in order to either improve it for future deployments, or to identify concerns which will need to be addressed.
In general, I am happy with the way the software ran, and speaking from a technical perspective, I am happy with the way the election was run. Better communication over the start time would have helped, but given that the election was run over a seven day period, the small delay would not have affected the outcome. The closure of the election went as well as hoped, and the counting was reportedly smooth and problem free. The problem that arose in regard to the missing email for one member is a concern, and would need to be better addressed in the future, but it did not prevent the member from voting in a timely manner. The practice of only accessing the server in the presence of the Returning Officer or a delegate was effective and did not raise any concerns, and provided two pairs of eyes to ensure that no mistakes were made.
I was especially grateful to John Vandenberg, Charles Gregory, and especially Steven Clark. Their assistance was professional and invaluable throughout the election.
Adam Jenkins, 2012 Election System Administrator