This content might be obsolete as the page was archived following deprecation of the concept of FINOS Programs in early 2020. For the latest on FINOS Community Governance check the FINOS Community Github Repository, and specifically for Decision Making see respectively Software Projects Governance and Standard Projects Governance. |
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:
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.
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:
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 |
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).
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. |
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:
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. |