Skip to main content
SearchLoginLogin or Signup

5. Decision Making: Seeking Consensus, Voting, and Elections

Published onApr 30, 2022
5. Decision Making: Seeking Consensus, Voting, and Elections
·

This chapter discusses various ways in which open infrastructure organisations can make decisions. It focuses first on forms of consensus-based decision-making processes, before considering when, how, and why it might be appropriate to have recourse to an informal or a formal vote.

Rather than seeing consensus-based decision-making and voting as two alternative methods, we suggest that better practice is to see them as complementary. Having clear voting procedures in place can in fact encourage consensus-building, allow space for productive disagreements to be explored, and ensure the best final outcome. We also warn against the dangers of imposing consensus where none in fact exists, and note how the use of formal or semi-formal voting, including such measures as indicative votes at the beginning of discussions, can allow voices that are sometimes marginalised or drowned out to be heard. This section also looks at how elections to boards and committees can best be run, as well as some of the risks involved and how these can be minimised. The section concludes by exploring the possibilities that adopting some form of ‘liquid democracy’ (a method of blending direct and representative forms of democracy, usually through the use of digital technology) may provide for open infrastructure organisations, while also noting some of the potential obstacles in relation to conflicts this could create if not incorporated properly.

Consensus

At its best, consensus decision-making processes are characterised by cooperation, egalitarianism, and inclusivity, and can result in better decisions being made, with the support of the whole community. Consensus decision-making processes have been particularly associated with anarchist groups, being employed in anything ‘from tiny affinity groups to gigantic spokescouncils of thousands of people’:

In consensus process, everyone agrees from the start on certain broad principles of unity and purposes for being for the group; but beyond that they also accept as a matter of course that no one is ever going to convert another person completely to their point of view, and probably shouldn’t try; and that therefore discussion should focus on concrete questions of action, and coming up with a plan that everyone can live with and no one feels is in fundamental violation of their principles (Graeber, 2004: 8).

However, there are many different models of what constitutes a consensus and how it should be arrived at, drawing from communities of practice as diverse as Quaker meetings, Japanese corporations and the Haudenosaunee (Iroquois) Confederacy Grand Council.1 Consensus means different things to different people. This is especially likely to be the case in infrastructure projects that bring together disparate allies from different institutional cultures and political backgrounds. It is important that where consensus decision-making is preferred, it is made clear in governance documentation which model is being adopted and how the existence (or otherwise) of a consensus is to be measured, as well as what procedures are to be followed when no consensus can be reached.

Some of these models, such as the spokescouncil model widely used by social centres, workers’ cooperatives, and peace and environmental movements, are designed to enable consensus decision-making among groups of hundreds and even thousands, and can be quite complex, with their own terminology (‘fish bowls’, ‘spokes’), specialised roles (‘empath’, ‘consensor’), and even a repertoire of hand-signals. It seems likely that the movements for open scholarship, education and intellectual exchange have a lot to learn from such models (easy as they occasionally are to make fun of) and this is an area in which much more work needs to be done. Organisations looking for more formal structures and procedures by which to arrive at legitimate consensus-based decisions are likely to find such work particularly rewarding.

For most community-led open infrastructure organisations, however, the more minimalistic, stripped-back consensus models generally favoured by open source projects will be more immediately applicable. Two such models of consensus decision-making are outlined below. ‘Lazy consensus’ is a lightweight solution especially recommended where most decisions are not expected to be controversial but nevertheless require the oversight of the larger community. ‘Rough consensus’, while a more problematic model, may be an appropriate solution for some organisations in certain situations. In most cases, however, consensus is probably best seen as a goal to aspire to and aim for which is best tested for and registered through some form of vote. This can often be done quickly and informally (or semi-formally), using tools such as indicative voting and Apache voting (see below).

Any over-emphasis on consensus, however, can have negative consequences no matter what model is chosen, stifling dissenting opinions and neutering creative disagreement. In ‘The Tyranny of Consensus’, M. Treloar describes how consensus decision-making has often been imposed from above or promoted by a largely white, middle-class community in ways that fracture the fragile alliances that hold together the ‘community of communities’ seeking change. As Treloar puts it, the ‘notion embedded in consensus process that ‘everyone will eventually agree if they talk about it long enough comes as a complete and unpleasant surprise to many groups with roots sunk in the working class or communities of color’ (Treloar, 2003).2 An analogous truth applies in the world of scholarly communication. Like Treloar’s black and working-class activist groups that ‘have learned by painful experience that there are clear divisions in society’, the small publishers that have been at the front line in fighting for open access and promoting the values of open scholarship, often at considerable personal cost, ‘have also learned that no group in history has ever given up its wealth or power through consensus process’ (Treloar, 2003).3 More generally, as is discussed in more detail in the section on voting that follows, consensus decision-making brings its own risks and should not be seen as a straightforward, comforting panacea to the difficulties of decision-making in the face of real disagreements.

Lazy consensus

Lazy consensus is a method of decision-making in which ‘silence equals consent’. The exact manner in which lazy consensus operates varies from project to project, but in its most common form, any member of a project can put forward a proposal. If no one objects or calls for further discussion or a vote within a pre-established time-frame, then the proposal is considered to have the support of the community and be approved. It is commonly practiced via group email or online discussion boards and collaboration platforms such as Mattermost.

Lazy consensus can be especially useful in situations where serious disagreement is not anticipated and it is important to keep governance lightweight and a project fast on its feet while also maintaining a degree of oversight. This method has been commonly employed in open source communities in particular (see, for example, Apache, gem5, Velero4), where it would be impractical for every minor change to a codebase, for example, to be discussed in detail and voted upon. For those doing the majority of the work it can be enabling, allowing them to proceed without having to refer every decision to a meeting or vote. It also allows all project members to be as actively involved in decision-making processes as they wish, and to focus on areas they know most about.

Any organisation employing lazy consensus decision-making will need to think carefully about (and periodically revisit) how long to allow for objections or calls for further discussion to be made. Apache normally allows 72 hours, for example, though it notes that this period may need to be extended where it overlaps with a weekend. Others allow longer: Velero allows 5 days, while gem5 allows two weeks. This latter requirement is put in place to ensure that ‘everyone is given enough time to read, digest and respond to the proposal […] and to be as inclusive as possible of all participants, regardless of their location and time commitments’. Additional factors to consider include members working across different time zones; members contributing to a project on a part-time basis (especially likely to be the case on open infrastructure projects); and the platform used and different cultures and expectations around these. Online collaboration platforms can be a good way of keeping project proposals and discussions distinct and allowing for more rapid decision-making; for many project members with overflowing inboxes, emails about project proposals may risk going unnoticed until the time for raising objections has elapsed.

For open infrastructure organisations, lazy consensus can be especially useful where an individual or a working group is tasked with a relatively self-contained sub-project which nonetheless needs a degree of oversight, and for its decisions to be visible to all project members for the sake of transparency. For instance, an infrastructure organisation in which new members will need to be brought on board quickly and smoothly might establish a working group to evaluate and approve (or reject) applications, rather than wait for an AGM and/or have all members or a board of trustees formally vote. The working group’s decisions might then be put forward as proposals on a lazy consensus basis, with the group’s decision being accepted in the absence of any objections. Only in the case of an objection or query arising would a wider discussion and vote then be required.

It is worth bearing in mind, however, that in some cases it may be both more empowering and more efficient to give individuals or working groups the autonomy to make their own decisions. This can include the option of referring any decision to the wider community, whether through lazy consensus or a more formal discussion and vote. (This is commonly done when a working group cannot itself arrive at a unanimous consensus.)

Lazy consensus has proved its value as a powerful tool for streamlining decision making: where adopted, though, it should be as one element in a tiered decision-making process. As Gabriel Hanganu notes, ‘not all decisions can be made through lazy consensus: issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote’ (Hanganu, 2013).

Strengths

  • Lightweight and efficient - minimises meetings and governance workload, and allows those doing the work to proceed with mimimal delays;

  • Flexible - accommodates differing (and fluctuating) levels of engagement in decision-making by individual members;

  • Focused – encourages members to focus their governance efforts on their areas of expertise, without restricting them to doing so.

  • Horizontal and egalitarian - in its most common form, it allows any member to propose and follow through a course of action, or raise an objection or call for further discussion;

  • Adaptable – can be modified to suit different contexts, from small working groups to wide memberships; ability to make proposals, raise objections, or call a vote, while generally open to all, can be restricted where appropriate.

Limitations & Considerations

  • Requires platform buy-in – relies on all members committing to the chosen decision-making platform.

  • Not suitable for all decision-making – issues of strategic direction and legal standing should go to a formal vote.

  • Relies on a ‘sweet spot’ of engagement – if enough members do not monitor proposals and intervene where appropriate, a few over-zealous actors can take control and bad proposals can be approved. Conversely, if every proposal is met with an objection, then lazy consensus ceases to function.

  • Requires the support of a voting system – like all forms of consensus decision-making, lazy consensus needs to be backed up with some method for reaching a final decision when a consensus cannot be reached.

Rough consensus

In situations where a unanimous agreement cannot be reached, a decision must (usually) nevertheless be taken. The most common solution is to resort to some form of voting. Forms of ‘rough consensus’ provide an alternative. Peter Resnick of the Internet Engineering Task Force (IETF) notes that while unanimity is ideal, IETF meetings don’t require it. One of the problems with many consensus models is that, as Resnick puts it, they allow ‘a single intransigent person who simply keeps saying “No!” to stop the process cold’ (Resnick, 2014). At IETF, working group chairs are empowered to declare the existence of a ‘rough consensus’ if they determine that an objection has been fully considered and answered by the group, or does not identify a significant enough problem to justify not moving forward.

Despite its obvious advantages in terms of speed, rough consensus places significant power in the hands of the chair and without controls in place could be open to abuse. When combined with a quick informal vote, however, rough consensus in some form may have a place in community-led open organisations that need to be light on their feet and whose chairs have the community’s marked respect. In general, we would recommend that any decision based on rough consensus be supported by an informal vote (a show of hands, a +/-1 in a chat channel or email thread) that requires a supermajority of at least two-thirds of those eligible to vote—or in other words, on a rough count more than twice as many people have to support a motion as oppose it for it to be carried.

Consensus Decision-Making: Further Reading & Resources

Voting: When and How to do it

For open infrastructure projects that need agile forms of decision making, deciding (a) when a vote is necessary and (b) how to conduct it presents numerous challenges. It doesn’t help that the literature on voting and electoral systems is vast and hard to navigate. Without getting into technicalities or laying down any definitive ‘best practice’ (which will need to be adapted to an organisation’s specific situation, culture, scale, and maturity), this section (a) highlights the key questions and issues around voting, and arguments for and against; (b) presents some models which are widely applicable, simple to implement, and easy to tweak and develop, which organisations unsure where to start may wish to adopt; and (c) introduces a handful of more distinctive methods and interesting tweaks that might be of particular relevance to community-led, open infrastructure projects, especially those looking to refine or revisit already well-established decision-making procedures. For those wishing to explore voting models in more detail, a selection of useful starting points is offered in the ‘Further Reading’ section below.

When to Vote

‘The hardest thing about voting’, as Karl Fogel points out, ‘is determining when to do it’ (Fogel, 2022). The culture of many open source, community-led projects is such that consensus-building tends to predominate. This is especially true of smaller projects and projects in the earlier stages of development, where most or all participants are founder members and share a common understanding of the project’s goals and values. In such projects an actual vote is often not necessary to decide upon a course of action. Where opinion is split, it will often be evident who is in a minority, and that minority will often accede to the majority decision in order to maintain group cohesion and good feeling prior to any formal vote being taken.

For Fogel, therefore, taking a vote ‘should be very rare — a last resort for when all other options have failed’. Votes don’t end debates but do end discussion, he argues, and therefore also often end creative thinking about the problem. ‘As long as discussion continues, there is the possibility that someone will come up with a new solution everyone likes. […] Voting’s only function is that it finally settles a question so everyone can move on. But it settles it by a head count, instead of by rational dialogue leading everyone to the same conclusion’ (Fogel, 2022: 42).

The kind of consensus-based culture this presupposes is generally very healthy, and one of the most attractive characteristics of many community-led, open organisations, but it is accompanied by certain risks. One of these risks is the assumption that because decisions have hitherto been reached through discussion and consensus the same will remain true in the future. As organisations grow, often becoming broader coalitions of interests and views in the process, establishing – and even identifying – a clear consensus may become more difficult. This can lead to disagreement, tension, and ultimately organisational fragmentation and breakdown. Such periods of stress or crisis are often what prompt organisations to revisit their governance mechanisms, but in general they also provide far from ideal conditions for a governance overhaul. Having clear voting procedures in place well before they are needed or used, with clearly defined criteria as to when a vote can be called and by whom, can mitigate such problems, and facilitate continual iterative adjustments to address issues in the functioning of governance as they arise. Revisiting a pre-existing voting system when its flaws begin to show is likely to be easier and less disruptive than implementing voting from scratch. Rather than impinging upon or restricting ‘open’ organisational cultures of discussion and compromise, proper voting provisions can sustain and undergird them.

Even where a consensus does appear to have been reached through discussion alone there may be good reasons for taking some form of formal vote. A minuted record of a vote can provide an additional safeguard against later disagreements over what exactly was agreed, and a useful (and cathartic) means for dissent to be registered. Indicative votes, taken before discussion begins, can also be helpful: they can signal whether there is a clear majority in favour of a particular option, saving time and shaping the conversation, and quickly focus attention on potential issues and discussion points.

Voting (whether indicative or decisive) can also be valuable as a means to allow quieter, more reserved voices to be heard, especially in larger groups. In most decision-making fora a vocal, charismatic minority emerges that tends to dominate discussion.5 Where this minority is in agreement, an impression of a consensus can develop that does not necessarily reflect opinion in the wider group. This impression may also be shared by dissenting contributors, and make them less likely to articulate potentially important and influential counter-arguments. In such scenarios, there is a risk that decisions may be ‘agreed’ upon despite a majority opposing them.

Even where a vote confirms an apparent consensus, it can reveal the existence of a larger than expected dissenting minority, sometimes prompting reconsideration and further discussions. These in turn may result in a different, better, more nuanced final decision. Even where the decision remains unchanged, ensuring that the minority view is heard and acknowledged can protect against alienation and disenchantment, and ensure that such views are borne in mind in the future.

Elections

Stagger Elections and Terms of Office

Three years appears to be the most typical term of office for members on the board of trustees (or similar) for open infrastructure projects, commonly renewable for one or two terms.

Where a board of trustees, management committee, or similar is elected, terms of office and elections are best staggered. For instance, the Board of Trustees at UKSG (formerly the United Kingdom Serials Group) is made up of nine elected members, with a term of office of three years. Ordinarily, three members will be elected each year. This minimises the disruption caused, allowing for a relatively smooth transition, and ensures a good mix of experience and fresh blood. It also means that smaller elections are run more often. Both the electors and administrators are thus more familiar with the voting procedure, while the elections themselves are simpler to run, all of which makes errors less likely (and more easily remedied if they do occur).

Where a board is being established for the first time, consider differentiated initial terms of office. For example, the Open Access eBook Usage (OAeBU) Data Trust specifies in its ‘Governance Documentation for Initial Board of Trustees’ (2022-2025) that the normal term of office will be three years. However, ‘the first Board of Trustees will be elected as a single group, but will divide into three cohorts with up to 3 members of each cohort serving 1-year terms, 2-year terms, and 3-year terms so rolling cohorts are established’ (Elwell et al., 2021). The purpose of this is to combine a continual refreshing of the board membership with a degree of stability and continuity. This and other similar models have influenced COPIM’s discussions around the most appropriate way to establish the OBC’s Board of Stewards, the rationale behind which we will outline more in detail in future publications.

Beware Simultaneous Elections

Where an organisation has several elected boards or working groups, it can be tempting to run two or more elections simultaneously, on the assumption that this will minimise the administrative load, time taken, and organisational disruption. We caution against this, especially where different groups of voters and/or voting methods are to be used. The initial 2021 Board of Directors election at Open Source Initiative (OSI) offers a cautionary tale in this regard. Individual and Affiliate elections were run simultaneously and, partly as a result, ballots in the Individual election were incorrectly issued to (and in one case cast by) entities who were not eligible to vote.6 This ultimately led to two external reports being produced, with recommendations for the future conduct of elections. These included staggering the running of elections to avoid the ‘significant human and technical confusion between the two elections’ the reports identified.7

Document and Address Problems

The manner in which OSI documented and dealt with the problem also offers a model of best practice in acknowledging and addressing issues of governance in a transparent and thorough-going fashion. It shows too how having the courage to openly document moments of breakdown and failure can provide an invaluable service to the wider community of communities, in some cases far more useful than reports recording successes and ‘best practice’.

How to Vote: Voting Methods

The forms of voting used by open source, community-led projects vary, and many organisations do not clearly specify in their public-facing governance documentation how votes will be carried out. In smaller organisations or on relatively straightforward matters, a simple ‘first-past-the-post’ system of voting is likely to be adequate, often administered through a simple show of hands (or electronic equivalent). This has the great virtues of simplicity and clarity. The flaws of this system in more complex scenarios have been extensively documented, however, and it is worth considering whether an alternative method might be appropriate in certain circumstances, such as where a choice between multiple options or candidates needs to be made. The tendency of infrastructure projects towards organisational complexity also means that more sophisticated voting mechanisms may be more likely to be required.

At the very least, the rules by which any formal votes or elections are to be conducted should be documented and clear to all involved well before the necessity of any particular vote becomes apparent. Unless there is good reason for them not to be, these rules should also be made publicly accessible. Ensuring voting rules are clear and put in place in a timely fashion is generally more important to good governance than the choice of one particular voting system over another. That said, organisations should consider in advance whether the system of voting employed may be contentious or unfair. In general, the more a project is likely to be making use of formal votes in electing members and making decisions, and the greater the number of candidates and voters there are likely to be, the more seriously the project may need to consider its voting system. Governance documents should also clearly establish under what circumstances and through what procedures any voting system can be changed.

Approval Voting

Approval voting is a simple system in which each voter can vote for as many candidates (or options) on the ballot as they wish. It mitigates many of the shortcomings of the one-vote, first-past-the-post system, and is ‘a good choice in most cases’ because ‘it is simple to explain and to count, and comprehensibility is an important factor when choosing a voting method’ (Fogel, 2022). It is also simple to administer either electronically, by post, or in person, and can be used either to elect a single winner, or to elect multiple candidates (often useful when electing board members, for example) from a single ballot.8

Apache Voting

In the Apache voting system, votes are represented as numbers between -1 and +1: -1 means no, and +1 means yes.9 The in-between values indicate how strongly the voting individual feels. Their documentation gives examples of fractional votes and what the voter might be communicating with them:

  • +0: ‘I don’t feel strongly about it, but I’m okay with this.’

  • -0: ‘I won’t get in the way, but I’d rather we didn’t do this.’

  • -0.5: ‘I don’t like this idea, but I can’t find any rational justification for my feelings.’

  • ++1: ‘Wow! I like this! Let’s do it!’

  • -0.9: ‘I really don’t like this, but I’m not going to stand in the way if everyone else wants to go ahead with it.’

  • +0.9: ‘This is a cool idea and i like it, but I don’t have time/the skills necessary to help out.’

As Apache takes care to note, while ‘the community should spell out in its guidelines the tacit implications of voting […] in no case may someone's vote be considered invalid if it does not appear to meet the implied commitment: a vote is a formal expression of opinion, not of commitment’. Apache’s voting system is in most cases not suitable for making important strategic or legal decisions involving large numbers of votes. It can be extremely useful in smaller and more informal decision-making environments, however, and might be used for indicative votes and alongside consensus decision-making processes very effectively.

Condorcet Voting Systems

One voting system that has proved particularly popular with open source and community-led projects is the Condorcet method. Technically, this is a family of related methods.10 The basic principle of the Condorcet method is that voters rank their choices in order of preference, and these rankings are used to elect a candidate or to choose an option that beats all others in a pairwise contest. Elections can be conducted in various ways, but most Condorcet elections employ a single round of preferential voting. Adopted by the Python, Homebrew, and the Debian communities among others, Condorcet is widely regarded as the most fair, representative, and accurate way to tally ranked choice ballots for single winner elections. Digital and online voting applications (see, for example, condorcet.vote) make administering a Condorcet vote relatively straightforward. Forms of Condorcet voting are also often employed in Liquid Democracy (see below).11

‘Further Discussion’

Debian is an open source operating system developed by a democratically structured community spanning more than 60 different countries whose governance methods include the use of a version of Condorcet voting. The ballot for every Debian vote on a decision includes as a default a ‘Further discussion’ item.12 This gives the option for voters to choose further discussion over any or all of the other available options. There are several benefits to this. First, if a voter feels one or more options are especially bad, they can express this by ranking these options below ‘Further Discussion’: if enough voters do so, this will lead to more debate taking place before an option which many have very serious reservations about is chosen. It can also provide a useful indicator of options that the community - or substantial parts of it - is particularly hostile towards.

More often, though, at least at Debian, ‘Further Discussion’ reportedly loses by a large margin. While such results might appear to suggest that this option is redundant, they give a particular legitimacy to the result of the vote both within and beyond the project: as one commenter put it, the method produces ‘a nice number you can quote [...] (“look, not everyone voted for this option as their first choice, but 95% of dev[eloper]s like it better than continuing to discuss”)’.13 Recognition within the project that this decision was preferred over continued discussion can also increase buy-in and mitigate disillusionment on the part of those who did not vote for the winning item.

Casting Votes

Consider how tied votes will be resolved, and specify this in your bylaws. One way to prevent having tied votes is by having an unequal number of voters. When this isn’t a possibility or isn’t practical, the standard method to prevent a tie is through the use of a casting vote. In one common model the Chair votes as usual, but also has a second, casting vote in the event of a tie. An arguably fairer alternative sees the Chair initially withhold (or conceal) their vote, only ever voting (or revealing their vote) in the event of a tie. This latter method especially suits scenarios in which it is useful for the Chair to play a more neutral role.

Liquid Democracy

It is particularly common for infrastructure projects to bring together partner organisations from different fields and with different priorities in terms of what they want to gain from the project, and different foci within the project. One issue this can throw up is differing levels of engagement with the governance process: one partner or group of partners may wish to be actively involved in each and every decision, while another may wish to contribute to the project in other ways but see active participation in governance and decision-making as an unnecessary drain on their time and resources, and/or feel ill-equipped and under-informed to make certain decisions. This concern emerged repeatedly in COPIM’s governance workshops and discussions with potential community members and stakeholders. As a contributor to one of COPIM’s library workshops noted, participation might look different to different members, with potentially different resources: some might only want to stay informed via a governing body (and maybe have a say only in very major decisions), whereas others might want to participate directly and steer things more closely (Morka & Gatti, 2021).

This theoretical issue became more concrete when considering how academic libraries might best be accommodated in COPIM’s Open Book Collective. Some libraries are enthusiastic about joining the project as members and helping to shape the overall direction of travel, but as others explained they lack the resources and/or the desire to be engaged actively to its future governance.

For larger infrastructures with many members, a form of liquid democracy may offer a solution in such situations. With origins traceable at least as far back as Lewis Caroll’s Principles of Parliamentary Representation (1884), liquid democracy combines direct and representative forms of democracy, allowing voters to choose whether to vote directly on an issue or to delegate their voting power to a trusted party or ‘proxy’. For its advocates, liquid democracy has the potential to be a more egalitarian and flexible foundation for decision-making in virtual and open source communities. Through delegation, Dominik Schiener argues,

people with domain-specific knowledge are able to better influence the outcome of decisions, which in turn leads to an overall better governance of the state. Because of this, Liquid Democracy naturally evolves into a Meritocracy, where decisions are mainly made by those who have the kind of knowledge and experience required to make well-informed decisions on issues (Schiener, 2016).

This is likely to be especially attractive to an open source infrastructure project with heterogenous members who each have particular areas of expertise (and ignorance). The precise mechanisms through which liquid democracy is instigated vary widely, and depend in part on the scale and complexity of the voting and systems involved. It should be noted that liquid democracy is not itself a voting system: liquid democracy can use any voting system, from straightforward first-past-the-post, to some variety of Condorcet or quadratic voting. However, it is often seen as being especially suited to (or enabled by) online voting and communication, and is suitable both for electing candidates and for taking other kinds of decisions.

For most small or medium open source infrastructure organisations, some kind of system that limits when and how a voter can decide to vote directly or to assign their vote to a representative may be needed in order to keep administration manageable and trustworthy. With new, affordable software tailored to such organisations, however (see ‘Open Source Liquid Democracy Tools’ below), even smaller projects may be able to employ truly liquid decision-making processes. Several of these tools combine online discussion fora (similar to Mattermost) with voting and decision-making procedures, and allow for the expression of preferences, abstentions and the like.

Liquid Democracy Resources

Further Reading

Image 1

Liquid Democracy schematic. Source: Schiener, 2021.

Establishing a Quorum

The quorum is the minimum number or proportion of voting members that must be present for a meeting to conduct business on behalf of the group (and therefore for a vote to be conducted or considered valid). Setting a quorum too high may make it difficult for important decisions to be taken in a timely fashion, while setting it too low (or not having a quorum at all) risks allowing a small minority to impose its views undemocratically. A simple majority of eligible voters is a common default, but consider whether this is appropriate, and whether there are particular kinds of decision or meeting for which a higher or lower quorum might be appropriate.

For example, for meetings of the UKSG’s Board of Trustees, which usually consists of nine members, the quorum is three ‘or the number nearest to one-third of the total number of Trustees’, while for General Meetings, a quorum is one-twentieth of the membership entitled to vote, who must be present either in person or by proxy.14

It is common for all kinds of organisations to require a higher quorum and a greater majority for votes to make changes to a constitution or articles of association. Intelligent scheduling can help ensure a quorum is met. If trustees or directors are also members of an organisation, for example, then holding a members’ meeting immediately before or after a board meeting might make it more likely that the quorum for the latter will be met. If your project is international in scope, consider how different timezones might impact upon the ability to reach a quorum, and how all members can be given an equal chance to attend and have their vote count. If physical meetings will play a significant part in decision making, geography should be borne in mind for similar reasons.

If your infrastructure project is–or is planning to become–a legal entity (e.g., incorporating as a charity), check whether there are legal requirements or recommendations regarding quora for certain meetings. The UK’s Charity Commission, for example, recommends that the quorum for a trustees’ meeting is a minimum of one third of the total number of charity trustees, plus one (so a charity with twelve trustees, for example, will have a quorum of five.)15

Defining how a quorum is constituted in online decision-making is particularly important, especially where online discussion platforms such as Mattermost (or commercial alternatives like Slack and MS Teams) are used. Consider how attendance and abstention is to be indicated and recorded. A common form of voting in online fora is with either a +1 (yes/pro) or -1 (no/contra): here a 0 can function as an active abstention that contributes to a quorum being met.16

Jeremy Barlow identifies three ‘red flags’ that indicate requirements for a quorum should be reviewed: when a few members become too powerful; when the needs of the organisation change; when the organisation goes through a period of growth (Barlow, 2016).

Quora: Better Practice Recommendations

  • Check any legal requirements and recommendations that apply.

  • Which meetings or groups should have a quorum? (We recommend a quorum be set for all formal boards or groups that play a part in the organisation’s running and governance.)

  • Set a default quorum (one-third of voting members and a simple majority are common defaults).

  • Identify and specify any exceptions to the default quorum. Votes to change an organisation’s constitution or bylaws commonly require a higher quorum.

  • Specify quorum requirements unambiguously in your organisation’s bylaws.

  • Review quora regularly, looking out especially for Barlow’s ‘red flags’.

Online Voting and Software for Voting & Decision-making

Online decision-making and open source projects have long been closely associated. The COVID pandemic and the increasing internationalisation of open infrastructure projects have both contributed to making online voting increasingly the norm. (The UK Charity Commission’s guidance is interesting reading in this regard, laying out the provisional allowances for online voting and meetings.) For relatively small projects, discussion platforms and chat services like Mattermost can be used for decision-making and voting. As organisations grow, however, more complex and secure platforms may be needed. At the time of writing a developed ecosystem of open source software of this sort appears to be lacking, but this is a fast-moving field. Below are just a few options organisations seeking more sophisticated voting software might wish to consider:

  • ChoiceVoting - commercial voting and election management software aimed at charities and similar organisations, also used by the Green Party, University of Exeter and others. Pricing variable, from free for up to 20 voters and 2 elections, to £45 for up to 250 voters, and higher for more.

  • Civica CESVotes: see also here. A more expensive solution perhaps suitable for bigger projects.

Voting and Decision-Making: Questions to Answer

  • What kinds of decisions need to be taken?

  • Who should take each of these kinds of decisions? All members? a board or working group?

  • What mechanisms do you have in place to ensure all relevant voices and opinions are heard, especially those liable not to be?

  • What mechanisms do you have in place for decision-making when consensus breaks down?

  • Who, if anyone, needs oversight? Are you introducing unnecessary oversight mechanisms? Can you empower the people doing the work to make their own decisions, even if they are of lower ‘rank’ (however that may be conceived)?

  • What legal considerations apply to any decision-making/voting mechanisms you employ?

  • What voting system will be employed? How will votes be carried out?

  • Are there any circumstances under which it should be specified that voters must recuse themselves?

Voting: Guidelines for Better Practice

  • Stagger elections to boards and working groups, to ensure a mix of experience and new blood and minimise disruption.

  • Three-year terms, renewable for a single term, are a good default for most permanent or standing boards, but consider carefully if they fit your situation. Are there any decision-making groups within your organisation that should have longer or shorter terms? Be more or less renewable?

  • Consider using approval voting to elect board and working group members.

  • Consider whether some form of liquid democracy would (a) serve the needs of your organisation, and (b) be implementable.

Comments
0
comment
No comments here
Why not start the discussion?