Anti-Harassment Tools/SecurePoll Improvements

The Anti-Harassment Tools team worked on a project for doing targeted improvements to SecurePoll extension during January through March 2021. This project was a special request from the Wikimedia Foundation Board and the Trust & Safety team to get SecurePoll ready for the upcoming Board elections 2020. AHT team took a hiatus from IP Privacy Enhancement and Abuse Mitigation to work on this project.

As part of this improvement project, AHT is working on the following features:

Improving the ability to conduct scrutiny on an election activity

 * Added logging support for checks conducted by volunteers on voter data. SecurePoll now automatically creates a log entry every time an election admin accesses voter data for an election. It captures the timestamp of access and username of the admin. This election log is available for everyone to view.
 * Added logging support for admins added or removed from an election. Admins might sometimes be added too late in an election cycle to be able to do much effective scrutiny work. To mitigate this, we have added logging for when admins are added or removed from an election.
 * On top of this, we have added filters to the logs to allow quick search when investigating a case.
 * Only users in the election-admin group may now be added to a poll as poll admin.
 * Solved a security bug where admins could edit election settings post election-close.

Improving the poll administration experience
A complete list of all the tickets AHT worked on can be found here.
 * We converted major parts of SecurePoll to be OOUI-compliant.
 * Some election settings, such as changing election admins can now be done from the 'edit election' interface without having to access the database.
 * The Tally functionality, which required database access to get results earlier should now have speed-ups in performance. We are working on eliminating the need to access the database entirely.
 * We are adding a way to differentiate between partial and full blocks when setting voting eligibility requirements.
 * Solved several bugs relating to the election administration interface.

Implementing Single Transferable vote methodology


The Board Election Committee unanimously agreed in favor of using Single Transferable vote (or STV) for the upcoming Board elections. STV is a widely used methodology which has been adopted by several countries and organizations for holding their elections.

Two key benefits of using STV are:
 * It aims to reduce wastage of votes by allowing proportional transfer of votes. This means that even a voter's first choice of candidate is disqualified or already elected, their votes are transferred to their next preferred candidate. In an ideal election, every vote cast would count towards an elected candidate.
 * Promotes diversity in elected candidates by allowing better representation from minority groups. By allowing transfer of votes, STV seeks to achieve proportional representation of elected candidates from minority factions. An example of this in action can be found here.

Projected timeline
The Anti-Harassment Tools team predicts SecurePoll will be ready to be used with Single Transferable Vote by August 1st. A major chunk of this time period will be dedicated to conduct thorough testing in order to ensure there are no bugs (unintended features) in the system.

Methodology
Here is a short video explaining this process in more detail.
 * Calculate the number of valid votes.
 * Calculate the Droop quota.
 * For each round of voting (one per candidate in the ballot list), find the candidate(s) who secured more votes than the Droop quota. These are declared elected. Their surplus votes are transferred to the next preferred voter candidate.
 * If none of the candidates meet the droop quota, the one with the least number of votes is discarded and all of their votes are transferred to the next preferred candidates for the voters.

Update: 27 May 2021
We have an update on some key decisions made regarding STV voting. The engineering team is consulting with User:KTC and User:Matanya from the Board Election Committee as we go through this process.
 * We have settled with using dropdowns to indicate vote preferences in the user interface.
 * Votes can only be made in a sequential order.
 * The same candidate cannot be picked as a choice for multiple options.
 * All candidates need not be ranked.


 * There is an ongoing investigation on phabricator into the various implementation methods for STV. Meek's method seems most promising.
 * We are adding more tests to the SecurePoll extension to make it more reliable in the long run.
 * We are improving the way Tallying works to make it more performant.

Update: 27 July 2021
We are close to the elections kicking off! Sharing some recent updates below:
 * The team has made a lot of progress on implementing the STV algorithm which was met with some blockers. We have been using OpaVote to validate our results however there are some design differences in how we implement the algorithm. We will be writing up a document to help voters understand how Single Transferable Vote works and how the results are calculated.
 * The result output for STV will look like the presented mockup. It will include details of the method followed for eliminating and electing candidates.
 * For the edge case of when candidates are tied with a single remaining seat, the decision will have to be made by the election committee on how to break the tie.

Update: 4 August 2021
Late last week (30th July) we enabled all the changes for SecurePoll on production cluster and attempted to kick off a test election. This resulted in several database errors. We are unsure about the cause of the errors as they did not show up on any of our test environments. The errors appear to occur because the election server connects to all other projects, causing a spike in database write transactions. We have fixed the issues and are actively testing them to make sure this does not happen again.