PollingVotingNotesAudioguy

AudioGuyWorkNotes - parent CommunicationSystems

• http://anonscm.debian.org/gitweb/?p=users/srivasta/debian/devotee.git;a=tree;f=examples;h=3c2da2c7524b14ecca52f21d0f961f72ae670c22;hb=refs/heads/master
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470995
• http://www.debian.org/vote/

Notes on the various polls of concern

(from the staff vote system, for reference, to have something to refer to)

There are really three completely different polling/voting systems being discussed: The poll on the main Soylent site. The need for a poll for the registered users of Soylent for major issues like the name change The need for a way to poll staff on issues that allows everyone to participate

1. The Slash Code Poll

This is the perl code on the slash site that is used for quickie polls. It is very much an 'ad hoc' system, and is open not only to registered users, but to anyone that goes to the site. It is easy to game this poll, it was never intended to be anything more than what it is. There has been some discussion of improving it in various ways. However, any attempt to improve it will at the least require some serious coding effort to integrate the changes into the rather complex Slash code system. Any attempt to actually make it MORE than an ad hoc poll, would face some extremely difficult problems related to armoring the code against cheating and abuse.

2. A poll for registered users for significant input on major issues

As a community based site, we clearly need some way to take the pulse of the community, in particular the registered users who support us. The most recent case is that of looking for name suggestions for the site, and voting on them.

The solution needed for this need not necessarily be integrated into the site, as it addresses a smaller group who we have means of contacting. So the programming problem is somewhat simplified for this case. However, with such a large group of people, there is still much potential for gaming the system and attempts to break it. So this is not a trivial problem to solve, and a number of approaches are being looked at. Whatever we pick or write needs to be pretty robust.

3. A poll/voting system to take the pulse of just our staff

Staff has it's own unique problems in this area which are completely separate and quite different from the two described above. (Staff voting system created and intended to solve this one)

Requirements for the #2 system - for registered users, 'our community'

• Needs to be available only to registered users
• Must allow only registered users to vote
• Must allow only one vote per user
• Must not be possible to 'fake' a user and vote, or otherwise 'hack' the vote
• Must be understandable to a larger group of people than just staff
• MAY need a way for users to submit poll items, or may not.

Additional requirements for specific issue of domain name suggestions and voting

In addition, we have an immediate issue which has some unusual requirements, which may be unique to this issue.

• Need way for domain name suggestions to be submitted without out opening this up to evil domain name squatters trying to profit off us.
• Need a way to insure we have clear title to the name selected

Quick look at Devotee

This is just some wuick first impressions, could be wrong. Want to have NC take a look at this as I think he has some direct experience with it.

Plusses

• Already written
• Apparently in current use at Debian
• Source available
• uses email
• uses ldap
• uses crypto keys, strong auth
• bash scripts and perl
• uses ranked voting, Condorcet method

Minuses

• Code base looks pretty old, most recent 2008 or so, may have problems with perl libs (same age as slash code). Am not personally excited about maybe having to debug old perl code ;-)
• seems very specifially designed for the Debian system of developers, who have clear access privileges
• ldap - not sure we want thousands of peole in our lday database with their fequent changes, and if a separate ldap was used, would be a duplication of the slash database in many ways
• managing crypto keys for some developers is one thing, for thousands or tens of thousands of users strikes me as an administrative nightmare
• Does not seem to be in their current base, at least apt-get was unable to get it. But my apt-get fu may be bad, do not use debian much. (have it in my remote server)

The philosophy here in the code was actually very close to what I am doing with the staff voting thing, caused me to laugh at one point. There really aren't that many ways to do simple voting. ;-)