Clarifying voting meaning and methods around broken consensus

[markwhiting]

Note

This proposal aims to formalize a method around the voting discussion happening in #21. However, it looks like it would not impact the outcome of that vote for us to take either interpretation of these votes, unless the breaking consensus options wins. i.e. if the original wins in either case then it wins, if the break wins in one base the proposal is broken, in the other case the specific changes of the proposal may be updated around the break in consensus. There are of course other potential interpretations but those are the only I've heard at this time. So, this proposal is to formalize this situation for sake of clarity.

The problem

Our governance documents describe several situations where we use a vote to understand the collective assessment of an issue, however, the documents don't provide specific details on the content and method of setting up the vote. This means that we may disagree on the legitimacy of a vote due to interpreting these documents differently from each other. In particular the documents' description of voting around broken consensus has this weakness, and is thereby causing a potential larger challenge in current business (e.g. recently votes on broken consensus).

NOTE: In this proposal, the specific problem of voting to resolve broken consensus is the focal point because that challenge is one that we are currently facing. Other kinds of voting are also important for us to resolve and can be addressed through other proposals.

The proposal

I propose we devise a simple metaphor for voting, and a simple mechanism to construct a vote. In other words. Make adjustments to the governance documents to introduce a specific interpretation of a vote and add a new template to let us set up these votes in consistent ways.

I propose we formally treat a vote as a way to compare an initial proposal and a proposal subject to specific suggestions outlined in the breaking consensus post. In that sense, if the initial proposal receives more votes of support then the original proposal achieves consensus at the end of the voting period assuming no other roadblocks. On the other hand if the breaking consensus post receives more votes of support, then the suggestions made in the break are to be included in an updated version of the proposal.

This introduces questions:

1. What happens if there's more than one break in consensus? This would lead to more than one vote, and in some cases votes at different times.
2. What happens if either outcome is unclear or impossible to implement? Before starting a vote we should have a formal procedure to collect the two parties' positions.
3. Does a voting period stop other activities around the relevant proposal? No, discussions, new breaks in consensus etc. can continue until a final consensus is achieved.

To run this, I propose we outline a specific set of steps:

1. Establish that a vote is needed at the weekly meeting through the existing guidance in the governance process.
2. Put a copy of the suggested proposal and the suggestions from the break in consensus into a google doc where these can be edited (mostly by the assignees and consensus breakers) to clearly represent the points of each party. Provide 48 hours from the time of the meeting for this to be edited.
3. A third party (someone who is not otherwise formally affiliated with the proposal) then posts this in the comments thread of the original proposal with a consensus voting template which describes the relevant instructions on voting activity and timeframe. The vote would be in a single post and would leverage emoji like ❤️ and 🎉 as opposed to thumbs, so as to avoid negative interpretation.
4. The vote then remains open until the following weekly meeting and is counted during the meeting.

Next steps: I will provide draft versions of the updated policy and consensus voting template based on the ideas outlined above before the consensus meeting this week.

Implications

In the short term, having a policy of this type will help us agree on what a vote does and how it works, to avoid tension around assumptions made in that regard. In the long term, this establishes a standard for us to cascade into other kinds of voting (e.g. a way to use a template to make a consistent vote).

---

Use comments to share your response or use emoji 👍 to show your support. To officially join in, add yourself as an assignee to the proposal. To break consensus, comment using this template. To find out more about this process, read the how-to.

[neilthemathguy]

BREAKING CONSENSUS

These things were clearly discussed on during the governance hangouts.

Can you summarize:

1. what was discussed during the governance hangouts
2. what was paraphrased in the document

[shirishgoyal]

Below is the understanding about the voting process as per governance hangouts.

By default, any submitted proposal passes consensus after a week from the proposal window. This is given when nobody breaks the consensus from the community.

If somebody breaks the consensus and people don't reach to the agreement for two weeks, it goes for voting.

Now, the voting process will list the two or more standpoints based on conflicting opinions. The Collective will vote for either of these options. Only one option can be voted by one member. From all the votes that these options gather, whichever proposal gains more than the majority (50% for two options and similarly) of the total votes given to all the options is considered to be the final decision of the community. Thus according to the governance process, strict majority is among the two or more standpoints. It is not about one standpoint receiving votes from 50% of the collective (in case of two options).

[markwhiting]

@neilthemathguy agreed. This is what we discussed in the hangouts, however, we did not discuss a final mechanism for voting, so it is the intention to specify that here.

Here's what the governance documents currently specify:

If there is no consensus on a proposal, the proposal remains open and the deliberation process continues in the subsequent weeks. In the worst case, the discussion has had no activity between two weekly deadlines, and no consensus has been achieved. In such a "deadlock" situation, a majority voting process is pursued for resolving the decision by all the members of the Collective. Votes are taken for one week, from weekly deadline to weekly deadline. The decision is made by a majority vote: breaking consensus requires a strict majority (>50%). In other words, voting in favor of breaking consensus — typically, not making the change the proposal is suggesting — requires greater than half the votes. If breaking consensus acquires fewer votes than a strict majority, then the consensus passes: the proposal is approved. Voting records will be made public so that there is accountability.

I'm more than happy for this mechanism to be iterated upon. I just think we need to make it clear so that we have a specific way of going about setting up and executing votes. I proposed the above way of doing it as one way for that to happen.

[neilthemathguy]

Thanks!

We did discuss the voting process and logistics in the governance hangouts. We collectively agreed on it and then the governance document was written and later paraphrased by @mbernst. As you (@markwhiting) and @shirishgoyal listed above we have clear and common understanding of the interpretation. We also discussed this in the last hangout attended by me, you (@markwhiting) @shirishgoyal @rvaish @mbernst @iceLearn. That's where we decided to put the proposal #21 for the voting. It is great that we all are on the same page.

We can paraphrase and reorganize the document so that process is more clear to ones who find it confusing.

Regardless of that--- for the current proposals we follow the process and interpretation we have agreed on. We have explained the shared interpretation and the process should carry on. It should not be halted.