How Should I Run My Community Elections?

Sooner or later in the growth of a community project, the question arises of how to choose representatives for the community. For some projects, this is when they lose a founder, and as a group decide to move to a “ruling technical council” model; for other projects, the need comes from the move to a non-profit governing body with paying members, and the desire to have a technical steering committee chosen from members; other projects evolve over time to a representative leadership model.

I have been involved in boot-strapping, reforming, or running elections in a number of different communities over the years (GNOME, Maemo, OpenStack, OPNFV, OpenDaylight, fd.io, and others). Which voting system to use, how to define the electorate, and limiting the pool of eligible candidates have tended to create the deepest rat-hole conversations in all projects I have been involved in when the topic of elections has come up.

The Python project, in the context of debating a governance change, recently put together a comprehensive survey of project governance and voting procedures, and voted to move to an elected Steering Committee model. This article attempts to synthesize some of the best practices I have seen used in various projects and elections, covering who gets to vote, who can be a candidate, and how elections are run.

Electorate and Eligible Candidate Pool

One project I recall had a situation where anyone who was registered for the site (a very low bar) could vote, but only project committers (a high bar) could be candidates in the election. However, almost all projects eventually converge on broadening the pool of potential candidates to equal the pool of voters. Anyone who can vote in the election is therefore eligible to become a candidate.

I have seen three main approaches for defining the electorate and candidate pools:

• High bar: Committers, maintainers, core contributors: voters are members of an “in” group, which involves long participation, and seniority recognised by peers
• Medium bar: "Active" participants, or foundation members can vote, as long as they pass some defined, and relatively low, bar of participation
• Low bar: Anyone can vote as long as they do some very basic thing like "signing up to the program" or "become a member of the members mailing list"

The kernel community TAB elections are an interesting exception: The electorate used to be "people who are in the room during the Kernel Summit party at which we hold the election". This has since changed to “people who are in the conference room where the election is held during the Kernel Summit”. For a couple of these, when the Linux Kernel Summit coincided with co-located Linux Foundation events, people with no kernel connections whatsoever have been able to vote just by going to the room at the right time. Personally I think this disenfranchises kernel developers who can't make it to the Summit, but if it works for the kernel community, I guess it works.

Defining the activity metric and minimum bar for what qualifies as participation can become contentious, mainly because where you draw the line will be arbitrary, and will omit people who you want to include, or include people who you want to omit. For example, if you set the bar at the minimum contribution level of one commit to the project, you omit all whose contributions are significant but not code related. The typical fear is ballot stuffing or cohort effects -- where large companies will dominate the representative bodies by having a large voting bloc, or where friends of candidates (or people with a certain agenda) will pass the low bar to become voters just to vote for their candidate.

One community I am familiar with required one patch submission in last 12 months be a voter. Other projects require 20 or 25 “contributions,” including patches, patch reviews, wiki page edits, and a variety of other types of measurable contribution. Another project had a hybrid "karma" metric made up of weighted amounts of different contributions (one code contribution was worth five wiki edits and twenty emails or forum posts). Other projects require people to request becoming members to vote (or allow those not covered in the automated bar to apply for a waiver).

Generally, some ongoing participation, which can be quantified in some way, is needed to be part of the electorate.  This group includes many more people, some of whom are passive participants in the community, or who “join” just to vote in the election. In my experience, fears of ballot stuffing and cohort effects are unfounded, but the risk exists. Technical communities tend to try to create rules to defend against possible abuses of the system, but this can be considered as premature optimization, which Donald Knuth has famously described as the root of all evil. It is better to avoid special rules to begin with, and address issues with the electoral process as they arise.

One final consideration is the process for becoming a candidate in the election. A few options exist, all of which seem to work. The most popular is self-nomination. Candidates post to a certain place with their reasons for running and any other information relevant to the election. Another option is nomination -- which often amounts to the same thing, as the candidate typically will have to ask people to nominate and second their nomination. Either works, just pick one.

Voting System

Anther guaranteed rat-hole conversation is the voting system. Here Be Dragons! In any community, there will always be two or more people who are passionate about how to vote, and how to count votes. These conversations can go on for months, and end up with proposals that are almost impossible to implement, if you are not careful.

One organization I recall wanted to increase the mix of representatives to include core and non-core projects. The small group who volunteered to define the election process defined project groups, and categorized candidates and electorates for each project type, then used a fancy proportional representation formula to choose the Technical Steering Committee with a quota of members from both groups, while simultaneously satisfying vendor diversity rules. Over-engineered and confusing.

Most community projects I am familiar with have tended towards the following:

• Voting by secret ballot
• Online voting, with a personal token to ensure one person, one vote
• Some form of preferential voting (list candidates in order of preference)
• Either Condorcet or Single Transferable Vote to count the votes and identify winners

Some projects continue to use alternative voting systems like "first past the post" or weighted voting systems, where you get 12 tokens to "spend" on whichever candidates you want, and the candidates with the most tokens at the end win.

Several projects use online counting software - several options to consider:

• Condorcet Internet Voting System is a free, online voting and Condorcet counting system
• OpaVote (formerly OpenSTV) is a commercial election counting software as a service
• OpenSTV used to be available under the GPL, and the last open source version has been conserved for posterity, and is used by several projects to count their elections
• Helios is another free election service, used by several projects, which allows online voting, and enables vote counting with several counting methods

How Should I Start?

My suggestion, if you are going to propose or boot-strap an election system, is to start with a mission statement. For example: "the goal is to ensure the technical steering committee represents everyone contributing actively to the project, valuing non-code contributions equally to code contributions, in the definition of the technical scope and direction of the project". This mission statement will identify a few things: who is being represented by the elected body, and what their authority will be (or why they are being elected in the first place).

Once you agree on the goal of the elected body, choose the absolute simplest ways to define membership in the body being represented, and the absolute simplest voting and counting system possible. For example, following on from the mission statement above, you might decide that a TSC size of 9 is appropriate to represent everyone, and include anyone with at least one code commit, documentation commit, wiki edit, or event participation (presentation or booth) in the membership list, and run a simple voting system where the top 9 candidates are elected. People fear that the system will be gamed with ballot stuffing, and voting blocs, but this happens way less often than people fear.

Especially in community projects, the vast majority of project participants have the best interests of the community (as they perceive them) at heart. Until you are proven wrong, trust your community to choose representatives who reflect the diversity of views they are representing.

(Image courtesy of Dude7248, licensed in the public domain.)