carbon-lang/docs/project/consensus_decision_making.md

Consensus decision-making

Carbon's teams will use a blocking consensus decision-making process to make decisions on proposals. We want all voices to be heard; we expect to iterate, identify and address concerns in order to reach consensus. A decision is approved when there is full agreement, although some team members may actively choose to stand aside.

We expect most decisions to be made in public, although some exceptional decisions will be private if a team member requests it. In any case, it's expected that only the reviewing team will actively participate in consensus discussions.

Main consensus process

Any team member involved in a decision may object and break consensus. Dissenters should present their concerns, ideally with proposed fixes. Another round of discussion may occur in order to address concerns. The goal is to ensure that team members are empowered to surface narrow but critical concerns that may only be noticed by a minority.

Team members have a fundamentally different role while working towards consensus on a decision than at other times on the project. They are expected to:

• Set aside personal advocacy and preferences, and focus on the best decision for the project and community.
• Critically evaluate whether their concerns are severe enough to warrant blocking.
• Focus on the information presented in a proposal, rather than adding new information. If new information is needed, the request for it should be the decision.
• Recognize their own biases and stand aside when unable to form an objective position.

More about consensus decision making may be found from "On Conflict and Consensus", and https://www.consensusdecisionmaking.org/.

Formal decision content

A formal decision consists of:

• The decision itself.
• A summary of the decision rationale.
• A summary of important discussion points.

Here are some possible decisions with their meanings:

• accepted: Yes, we want this now.
• declined: No, we don't think this is the right direction for Carbon.
• needs work:
  • We need more information or data before we can decide if this is the right direction.
  • We like the direction, but the proposal needs significant changes before being accepted.
• deferred:
  • We like the direction, but it isn't our priority right now, so bring the proposal back later.
  • We aren't sure about the direction, but it isn't our priority right now, so bring it back later.

When a proposal has open questions, the formal decision must include a decision for each open question. That may include filing GitHub issues to revisit the open questions later.

Each decision should have a rationale based on Carbon's goals, priorities, and principles. When the rationale requires explanation, the application of these goals should be documented. The reviewing team should check any relevant prior decisions and update or resolve inconsistencies in order to have a clear and consistent application of Carbon's goals.

At times, the goals, priorities and principles will simply not cover or provide a way to make a decision. In that case, the reviewing team is expected to shift the discussion to start with adjusting the goals, priorities and principles to cover the new context and questions. This should then be the first decision they have to make, and the technical decision should only be made afterward, so that it can cite the now pertinent goals, priorities and principles.

Meetings

In order to ensure we can rapidly make decisions, each team will have a standing weekly meeting slot, which observers may attend. Members are expected to do their best to keep the slot available. Meetings will be held using Google Hangouts Meet.

Each time a team needs to make a decision, for example, about a change to Carbon, it is expected that we'll try to make a decision without using a live meeting. We will only hold meetings when decisions cannot be resolved before the meeting.

Agenda

An agenda will be maintained for upcoming meetings. If there are no agenda items, meetings will not be held.

Agenda items, such as proposals, should be added at least one week or four working days in advance, whichever is longer, so that members have time to review items added to the agenda. Sub-items, such as proposal discussion points, should be added at least one day before the meeting. Please feel free to add items to the agenda and remove them later if the agenda item is resolved over other communication forums.

Team members are expected to prepare for the meeting by ensuring they're familiar with the proposal and related discussion. The meeting will not include any presentation or summary. Discussion will go over the proposal's agenda item and sub-items, with each agenda item resolving with a decision.

Roles

As part of organizing a meeting, we will have two roles:

• A moderator who is responsible for ensuring discussion stays on track.
• A note taker who will record minutes for each meeting.

Roles should be known before each meeting. These may or may not be staffed by reviewing team members; anybody taking a role should plan to be less involved in discussion in order to focus on their role. The roles should be handled by different people.

During the meeting, the moderator is responsible for ensuring we move in an orderly fashion from topic to topic. Meetings will have a Discord Chat that the moderator will watch. Attendees should let the moderator know whether they want to speak to the current topic or a new topic, and will be added to the appropriate queue. When it's the next person's turn to speak, the moderator will indicate whose turn it is. If there are few enough active participants, we may choose to skip the queue for a meeting.

The moderator is also responsible for ensuring discussions stay on track. Only the moderator should interrupt speakers or speak outside the queue, and the moderator should do so if discussion isn't progressing. The moderator is also responsible for polling for consensus on decisions during the meeting.

All team members should keep in mind that the ultimate goal of each meeting is a decision, and to consider what they discuss during a meeting in keeping with that goal.

There may be multiple review managers in a meeting, depending on the number of proposals being reviewed. Each needs to make sure they know decision information for the proposal they're managing when the meeting ends.

Observers

While community members outside of the team may attend meetings, they are expected to be passive observers. They should only speak if prompted by a member of the team, such as when a team member asks a question to a proposal author. Community discussion belongs on forums, and the meetings are for team discussions and decisions.

Unavailable team members

If a team member is asked for a pre-meeting decision and hasn't responded by two working days before the meeting, the team may assume they're unavailable and standing aside. The intent is to avoid unnecessary meetings. Not responding is strongly discouraged; please respond if you want the meeting.

Team members are encouraged to notify others when they're on vacation or otherwise unavailable for a while, and add it to the shared calendar. Members are also encouraged to stand aside from decisions if unavailable for more than half a week. If they have a specific interest in a topic or decision, they may ask for a delay while they're out.