Decision Making: Martha's Rules?

[ebullient]

I'd like to expand a little in the bylaws on how decisions are made. Here is the current, relevant content:

General Decision Making

True to Open Source roots, the CF ensures every member's voice is heard through the Lazy Consensus decision-making model.

To quote the Consensus definition from the Apache Foundation:

Consensus

The word “consensus” is a bit ambiguous in English, and so can lead to some misunderstandings of intent when we use it in the context of project decisions. Consensus does not mean that everyone agrees on all details. Rather, it means that the project, as a whole, has arrived a decision, or at least a compromise, that everyone can live with.

Lazy Consensus

Lazy consensus is the first, and possibly the most important, consensus-building tool we have. Essentially lazy consensus means that you don’t need to get explicit approval to proceed, but you need to be prepared to listen if someone objects.

When seeking consensus, members should express objections or dissent as early as possible to ensure there is time to discuss and address objections.

Every member, regardless of their role or contribution level, has an equal voice and is entitled to one vote in all decisions.

Seeking consensus in meetings

When an agenda item has appeared to reach a consensus the moderator will ask "Does anyone object?" as a final call for dissent from the consensus.

If an agenda item cannot reach a consensus a CFC member can call for either a closing vote or a vote to table the issue to the next meeting.
The call for a vote must be seconded by a majority of the CFC or else the discussion will continue.

For all votes, a simple majority of all Voting CFC members for, or against, the issue wins.
A Voting CFC member may choose to participate in any vote through abstention.

Seeking consensus on mailing lists

When seeking consensus in mailing lists, it is important to leave enough time (at least 72-hours) for everyone to read the email and respond with opinions and objections.

CFC members should consider the following when drafting consensus-seeking email:

• Use a leading indicator ([DISCUSS] or an emoji like 🗳️) to mark consensus-seeking email
• Use a clear subject line that summarizes the topic
• If there is a time constraint to the decision, include it in the subject.

It is customary for the initiator to post a summary once it appears that consensus has been reached, to ensure that their understanding is accurate.

To tie this loose idea of consensus into an async-digital form of communication based on GH Issues and discussions, do we bring in language from one or both of these sources (please feel free to try them out in practice in this very discussion):

• Edit: https://third-bit.com/2019/06/13/marthas-rules/
  • https://third-bit.com/files/2020/08/marthas/
• Adopt Martha's Rules for asynchronous consensus building hpc-carpentry/coordination#28

Here is another description of Martha's Rules: https://www.mannpublications.com/mannreportmanagement/2017/05/16/thumbs-up-for-faster-meetings/

[kenfinnigan]

I really like the idea of Martha's Rules, especially the notion of having a sponsor, or steward, to guide a proposal from beginning to end. Proposals can quickly lose progress without a singular person being responsible for its progress.

[trustin]

I like the idea and thanks for introducing Martha's Rules to us, @ebullient. One concern though:

the facilitator calls for a yes-or-no vote on the question: “Should we implement this decision over the stated objections?” If a majority votes “yes” the proposal is implemented. Otherwise, the proposal is returned to the sponsor for further work.

We need to define 'majority' here - 50% of all counsil members, 50% of attended counsil members, or should we choose higher percentage, such as 80% (could be floored to # of people)?

[ebullient]

That's a good question, and is basically the source of all troubles .. ;)

This paper has one observation of how the rule worked in practice (happened to be with all women, but that's neither here nor there):
https://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1825&context=sociologyfacpub

What I find interesting are the alternate outcomes, which can include "defer until these two groups work it out".

Consensus is not the same as unanimous agreement. Having a clear resolution process for dissent matters:
https://en.wikipedia.org/wiki/Consensus_decision-making#Blocking_and_other_forms_of_dissent

Given the sense poll taken ahead of the issue, I could read it this way:

• You enter the meeting with informal data from GH issues (👍 , 👎 , 👀 )
• You take the sense poll before discussion
• There is disagreement, you let all sides speak (timed, etc)
• Then you vote: if the counted votes are majority-for (with no negative change after hearing concern), then I think it could go forward.

That is with the assumption that the proposal has been pre-socialized, there has already been some discussion on it and effort taken to resolve concerns before the meeting. So the vote is the end of the process if there was disagreement.

[kenfinnigan]

This raises a good approach we should look to take, in that "discussion" for the most part happens async prior to a meeting. The meeting is then more often a formalization of the agreement, either for or against, as opposed to discussion from zero

[ebullient]

I did not include exact text for this in the PR. Required percentage of vote is the most relevant for CF matters requiring super-majority (where the number of required votes is essentially fixed).

If we want more specificity here, let's work on the language in PR #48

[ebullient]

As an assist, we can have a discussion category for proposals, that would include a template w/ reminder of the scale to be used for "sense" voting: https://github.blog/2023-01-09-github-discussions-just-got-better-with-category-forms/

[ebullient]

Consensus to go ahead. PR: #48