Page tree
Skip to end of metadata
Go to start of metadata


The Foundation encourages decisions to be made via thoughtful consensus building, aimed at achieving unanimous agreement.  It is unrealistic, however, to expect unanimity to emerge in all cases in a non-hierarchical community, and it is also undesirable to stall decision making perpetually in the event that unanimity is unachievable - this undermines confidence and sabotages any nascent collaboration.

To that end, the Foundation recommends the use of votes for any substantive decisions that cannot reach unanimity within a reasonable amount of time.  Once it is accepted that unanimity cannot be reached on a given decision, it should be put to a vote as soon as practical - a conclusive vote result, even in the negative, is vastly preferable to the uncertainty of indecision.

Voting Mechanic

Conceptually, the voting mechanic involves a single-subject yes/no motion, to which eligible voters can respond with any one of:

  1. In favor

  2. Abstain

  3. Not in favor

Voting, unless otherwise noted, is conducted entirely in public to ensure transparency and auditability of the process and results.

A vote may be initiated by any member of the body where the vote is taking place, and is sent to all of the members of that body.  This initiation notification MUST:

  • Be clearly labeled as a vote.

  • State the motion as a succinct yes-or-no question.

  • Contain instructions on how to cast a vote.

  • Include a deadline - the recommended default is 3 business days (72 hours) from initiation.

  • If there are any supporting materials, they should be linked from the text of the motion, or inserted at the end (after the deadline).

Votes are cast publicly, and must state a single preference.  “Not in favor” votes MUST include a justification, and “abstain” votes SHOULD include a justification.  Invalid ballots count as abstention, but may be recast before voting is closed.

To pass a resolution requires an absolute majority (greater than 50%) of the responses to be “in favor”.

Once all eligible voters have replied, or the deadline has expired (whichever comes first), the initiator closes the vote by tallying the results and distributing them to the body, stating either “The motion passed.” or “The motion did not pass.”

The Foundation mandates the single-subject rule for votes - "omnibus" votes, whereby a number of unrelated items are packaged together then submitted as a single vote, are strictly forbidden. They discourage scrutiny, encourage riders and conflation of unrelated concepts, and allow other forms of bias (intentional and not) to influence the vote.

The Foundation also requires all votes to be phrased in terms of a binary yes/no question, in order to avoid the inherent problems of votes that offer 3 or more choices (the Condorcet Paradox, Arrow's impossibility theorem, etc.).

If multi-alternative voting becomes necessary, it is proposed that the Schulze voting method be used, as it minimises these inherent mathematical challenges and has been widely adopted by other Open Source and standards bodies (please note that this proposal has not yet been presented or approved, however).

Email Voting

The Foundation strongly recommends voting by email, as this is common practice among Open Source projects and foundations.  This follows the voting mechanic described above, with the following email-specific refinements.


Votes are initiated by sending an email to the body’s mailing list.  The subject of the email starts with "[VOTE]", followed by a brief summary of the motion.  The body of the email contains:

  • the motion, expressed as a succinct yes/no question
  • voting instructions saying to reply-all with one of:
    • +1 for an "in favor" vote
    • 0 for an abstention, providing a justification
    • -1 for a "not in favor" vote, providing a justification
  • the deadline for the vote
  • optionally, any additional contextual information, references, etc.
Example Vote Initiation Email
From:    Peter Monks <peter@REDACTED>
To:      Engineering Steering Committee <esco@REDACTED>
Subject: [VOTE] Approval of contribution CONTRIB-14
Following on from the ESCo meeting on 2016-08-09, I am requesting a vote to approve the Clojure wrapper library contribution (CONTRIB-14) as a Foundation-hosted open source project.

Do you approve this contribution?

Please reply-all with one of the following votes:
+1 (approve the contribution)
-1 (deny the contribution) because...
0 (abstained) because...

The vote is open for 72h (until noon US-PDT, 2016-08-12).

CONTRIB-14 can be reviewed in detail at

Casting a Vote

Votes are cast by replying-all to the original email (i.e. in public to the entire list), with a single +1 (in favor), 0 (abstain) or -1 (not in favor) preference, along with a justification where required.

Result of Vote

Once the vote has completed, the initiator of the vote confirms the results by sending a result email to the same mailing list.  The subject of this email starts with "[VOTE][RESULT]", followed by the same brief summary of the motion used when the vote was initiated.  The body of the email contains:

  • the final tallies of each vote type (+1 / 0 / -1)
  • either the statement “The motion passed.” or the statement “The motion did not pass.”, depending on whether a majority of +1s was received.
Example Vote Result Email
From:    Peter Monks <peter@REDACTED>
To:      Engineering Steering Committee <esco@REDACTED>
Subject: [VOTE][RESULT] Approval of contribution CONTRIB-14
+1: 4
0:  1, because of non-response
-1: 0

The motion passed.

Ratification Notice

This voting process was instituted by resolution during the 2016-01-29 ESCo Meeting.

It was subsequently refined, based on the ESCo's ratification of a package of governance refinements, on 2016-12-01.

  • No labels