Online voting – The motivation, the fuckup and what we learned.

Motivation

We have been experiencing some practical dificulties the past years when executing voting. First of all 300+ participants take up alot of space, and the method of having people place a single token on a game of their choice has its flaws. Just to mention a few:

Some games are better exposed than others because they are in front.

The voting process is in plain sight, which can affect the result because of strategic voting.

The method suffers from the spoiler effect, meaning similar games share votes and sink into oblivion.

People are rushed to make their choice.

The solution we wanted to apply to this problem is best described in this video describing the Alternative Vote method. Basically we allow each voter to rank candidates in the order of their preference on a single voting card.

The method goes as follows: First the cards are placed on their primary candidate and the votes are counted. If more than half of the cards is on the candidate it is a winner, if not the candidate with least votes is removed and the cards are placed on their secondary candidate, and votes are counted again. This process is repeated untill a winner is found.

We expand the method further by also removing the winners, letting the remaining candidates fight for later positions.

With this design in mind we set forth to implement an online voting system in the management site (Django based) we were developing anyway. The task did not seem that daunting at the time.

The fuckup

When building software many things can go wrong therefore testing is very important and testing needs to happen in an environment as close to “the real thing” as possible. We implemented the voting feature in a hurry, and basically just barely had it “working” before the jam. Testing was limited to 30 users, and that was nowhere near the load we experienced during the voting ceremony. But to cut a long story short here is what went wrong.

Overload, our server was overloaded and produced a bug we ad not experienced with 30 users. (We were still on the Sqlite3 backend, next year we will go PostgreSQL)

A serialization bug ment that secret keys were sent to each client while voting. Essentially letting people vote as other people if they copied and pasted them. (Fixed, serialization module has been punished.)

A semaphore was not working as intended, leading to the “who are you bug” many experienced. (Minor rewrite of voting code needed)

Thanx goes out to the people reporting the bugs.

What have we learned?

First and foremost it builds character to pull the plug on an almost working system. Fortunately we had the backup in place, so we could proceed the oldfashioned way and produce a set of winners. Lesson learned: More testing and offcourse implement fixes for the beforementioned problems.

But when the dust settled we could cunt 1067 votes that were placed by 165 different accounts. Some of these votes could be placed by cheaters, but the spread and the winners produced gives us an idea that we were almost there. The votes show a nice spread throughout candidates, with a clear trend towards a small group containing the 3 winners produced by the backup method. Take a look for yourself in this screendump.

So expect a new attempt on the quest of finding the best games next year.