Background

All bodies within the Foundation have some level of decision making responsibility, and the precise mechanism used to make those decisions varies by body (and, in some cases, by the type of decision being made).

This page focuses exclusively on decision making related to community governance (and not corporate governance), as those kinds of decisions are by far the most frequent in our community. Specifically, the Foundation's community governance utilises a mechanism known as Governance by Contribution, a battle-tested system of open source governance that effectively formalises the concept of meritocracy. Decision making authority is earned via contribution and sweat equity, rather than by non-meritocratic factors (membership level, seniority, or employer, for example).

Governance by Contribution works by having those who've contributed to a work product share responsibility for making decisions regarding that work product. So for example decisions that need to be made within a Project or Working Group are made by the project team or working group participants themselves; Program level decisions are made by the PMC of that Program, and so on. While this may seem obvious, it's important to note that this is not typically how corporate decision making happens.

The specific decision making mechanic is defined in each Program's POP. For programs that use the standard POP, §II.D states:

Voting. The PMCs shall operate by consensus. If a PMC Lead determines that consensus cannot be reached on any substantive decision within the Program, a formal vote shall be taken within the PMC, with a tie vote being decided by the Program Liaison.

In other words, standard decision making is a 3 step process:

Decision identified - someone within the body identifies that a substantive decision needs to be made, and submits it to the body.
Consensus assessed - if there's consensus within the group, the decision is made and no further action is required.
- Technically this is done using unanimous consent (i.e. any objection is effectively a veto of the consensus, those not in attendance are ignored, etc.), though the Foundation doesn't require the use of any particular formal language.
- Currently the Foundation does not mandate a minimum quorum for consensus to be considered legitimate, but a minimum threshold may be introduced at a later date if this proves to be problematic.
Vote conducted - if consensus is not reached, a vote is conducted as soon as practical thereafter, using the voting mechanic described below.
- Moving quickly to a vote ensures that decisions are not stalled indefinitely - a conclusive result, even in the negative, is preferable to the uncertainty of indecision.

Voting Mechanic

Conceptually, the voting mechanic involves a single-subject yes/no motion, to which the eligible voters (i.e. members of the body to which the vote was submitted) can respond in exactly one of these ways:

In favor
Abstain
Not in favor

Voting, unless agreed in advance, must be conducted entirely in public, in order 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 (at least 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).

Responses to the vote are optional, cast publicly (unless the vote is private), and must state a single preference. “Not in favor” votes MUST include a justification, and explicit “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 non-abstaining responses to be “in favor”. There is no quorum (minimum number of responses) requirement, although this may change at a later date if it proves to be problematic. For PMC votes only, a tied vote results in the Program Liaison casting the deciding vote.

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 strongly encourages single-subject votes. So-called "omnibus" votes, whereby a number of unrelated items are packaged together then submitted as a single vote, are strongly discouraged as they inhibit scrutiny, encourage riders and conflation of unrelated concepts, and allow other forms of bias (intentional and not) to influence the vote.

The Foundation also encourages 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 a multi-alternative vote is necessary, the Schulze voting method should be used as it minimises these inherent mathematical problems and has been widely adopted by other Open Source and standards bodies. The Condorcet Internet Voting Service provides an easy-to-use, web-based implementation of the Schulze voting method.

Email Voting

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

Initiation

Votes are initiated by sending an email to the body’s public 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:    Adam Pmcmember <adam@REDACTED>
To:      Symphony PMC <symphony-pmc@REDACTED>
Subject: [VOTE] Approval of contribution of a Symphony REST API COBOL wrapper library
Body:
Following on from the PMC meeting on 2018-03-01, I am requesting a vote to approve the Symphony REST API COBOL wrapper library contribution as an open source project within the Symphony Program.

Do you approve this contribution?

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

The vote is open for 72h (until noon US-PDT, 2018-03-04).

More details of the contribution can be reviewed at https://finosfoundation.atlassian.net/browse/SYM-CONTRIB-72

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. So long as the vote remains open, respondents are allowed to change their response by replying again as if they hadn't replied yet (although doing so is discouraged, as it makes it harder to tally the result).

Casting a vote is optional - eligible members of the body who do not wish to respond to the vote can ignore it, thereby forfeiting their say in the decision (this is mechanically equivalent to an explicit abstain vote).

Example Vote Response Email

From:    Abhay Pmcmember <abhay@REDACTED>
To:      Symphony PMC <symphony-pmc@REDACTED>
Subject: re: [VOTE] Approval of contribution of a Symphony REST API COBOL wrapper library
Body:
0 because I don't feel qualified to vote on whether COBOL is appropriate for our Program or not.

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 ignoring all abstentions (both implicit and explicit).

Example Vote Result Email

From:    Adam Pmcmember <adam@REDACTED>
To:      Symphony PMC <symphony-pmc@REDACTED>
Subject: [VOTE][RESULT] Approval of contribution of a Symphony REST API COBOL wrapper library
Body:
+1: 2
0:  2, 1 due to non-response (Aya Pmcmember), and 1 because respondent didn't feel qualified to vote on whether COBOL is appropriate for our Program or not (Abhay Pmcmember).
-1: 1, because COBOL is not in widespread use in our community, and I'm concerned that this project will suffer from low interest & momentum (Amani Pmcmember).

The motion passed.