new decision process

book.toml

@@ -40,3 +40,6 @@ command = "mdbook-mermaid"
 "/initiatives/process/stages.html" = "how_to/propose.html"
 "/initiatives/process.html" = "how_to/propose.html"
 "/initiatives/stable.html" = "how_to/propose.html"
+"./decision_process.md" = "decision-making.md"
+"./decision_process/examples.md" = "decision-making.md"
+"./decision_process/reference.md" = "decision-making.md"

src/2-way-door.md

@@ -0,0 +1,30 @@
+# Reversible decisions
+
+Reversible decisions do not represent team consensus.
+Rather, they indicate that *somebody* on the team is in favor of the idea.
+We use them to begin experiments and do other small things.
+We never use them for decisions that impact stable code, such as stabilizing a feature.
+
+## Examples where this process is appropriate
+
+* Championing a lang-team experiment
+* Closing an RFC --
+    * Technically reversible (you can always re-open the PR), but particularly when external contributors are involved it's best to discuss this with the team beforehand. It's very confusing for people to have their PR closed and re-opened and can lead to burned bridges.
+
+## Process
+
+### Decision maker (lang team member or lang team advisor)
+
+* Write a comment on the Github issue or PR that
+    * Explains decision and context
+    * Labels the issue with `T-lang` (`@rustbot labels +T-lang`)
+    * Starts a `@rfcbot poll` -- typically the issue should *only* have `T-lang` to avoid excessive pings
+* If people raise concerns, particularly Rust team members:
+    * Remember to **treasure dissent**. Engage with them and make sure you understand it. Note all the concerns raised on the tracking issue as "unresolved questions" or things to explore so they don't get forgotten.
+    * Concerns don't *block* you from going forward, but they may give you pause, particularly if they are shared by many on the team.
+
+### Other team members
+
+* Since this action is reversible, your approval is not required. However, please check your box to indicate you reviewed the issue, it's useful feedback.
+* If you disagree with the decision, or think the experiment is a bad idea, say so (constructively)! 
+* For experiments, ask youself: What are the "weak spots" that the experiment ought to probe? What information can we gather?

src/SUMMARY.md

@@ -8,9 +8,9 @@
   - [Propose or extend a new lint?](./how_to/new_lint.md)
   - [Add an experimental feature gate](./how_to/experiment.md)
   - [Stabilize a feature](./how_to/stabilize.md)
-- [Decision process and principles](./decision_process.md)
-  - [Decision process examples](./decision_process/examples.md)
-  - [Decision process reference](./decision_process/reference.md)
+- [Decision making](./decision-making.md)
+  - [Reversible decisions](./2-way-door.md)
+  - [Consensus decisions](./consensus.md)
 - [Becoming and being a lang-team member](./membership.md)
   - [Lang-team leads](./leads.md)
 - [Chat platform](./chat_platform.md)

src/consensus.md

@@ -0,0 +1,78 @@
+# Consensus decisions
+
+Consensus decisions represent the official opinion of the team. They require that a majority of the team is in favor and that nobody has raised a concern that achieved [strong enough support](#threshold-to-resolve-a-concern-without-consent) to block the decision.
+
+They are used for for decisions that cannot be reversed (e.g., stabilization decisions or decisions that affect language semantics). They are also used for RFC approvals because, while the designs described there can be reversed before stabilization, we do not wish to do so lightly.
+
+## Definitions
+
+The decision making process distinguishes the following roles
+
+* **Lang team**: the [Language Design Team](https://github.com/rust-lang/team/blob/master/teams/lang.toml).
+* **Lang team member**: a member of the Lang team. Lang team members are the ones who have to [approve the final decision](#the-process).
+* **Advisor**: a member of the [lang team advisors](https://github.com/rust-lang/team/blob/master/teams/lang-advisors.toml). Advisors can propose a decision and can raise [formal concerns](#raising-concerns) but their approval is not required.
+* **Decision document**: the RFC, issue text, or other document describing the decision being made.
+* **Document author**: The person who authored the decision document. They ultimately decide what changes they wish to make to the text in response to concerns. They often do this in close consultation with a member of the lang team, but that is not required.
+
+## The process
+
+Consensus decisions are done using rfcbot. They always begin with a decision document authored by the [document author](#definitions). The document author can be anyone, they do not have to be a member of a Rust team.
+
+To make a decision, a [lang team member or advisor](#definitions) should issue `@rfcbot fcp merge`. This will create checkboxes. Once [2/3 of the boxes have been checked](#doing-the-math), the decision will enter final-comment-period. During that period the team should review any comments raised — assuming no concerns are raised (see below), the decision is finalized once the FCP has expired.
+
+*Note:* Before finalizing the decision, the team should engage with **new** points raised on the thread (particularly if they are made by people not able to raise formal concerns).
+
+## Raising concerns
+
+[Lang team members or advisors](#definitions) are entitled to raise a **formal concern** during the discussion process. This can be done with `@rfcbot concern concern-name`. The decision cannot be finalized until the concern is resolved, either because the person who raised the concern is satisfied and [resolves](#resolving-a-concern) it themselves, or because the team decides to [challenge it](#challenging-a-concern).
+
+### Expectations on raising a concern
+
+The [lang team member or advisor](#definitions) who raises a concern is expected to
+
+* write a constructive comment explaining the concern;
+* make themselves available for discussion in a reasonable fashion;
+* be prepared to write a document summarizing their concern for the lang-team if requested.
+
+### When a concern is raised
+
+When a concern is raised, the team will review the concern in the triage meeting. Based on that discussion, the [document author](#definitions) can decide whether they wish to make changes to mitigate or resolve the concern.
+
+## Resolving a concern
+
+If the person who raised the concern is satisfied, either because of changes made or because they don't wish to continue blocking progress, they should resolve the concern themselves with `@rfcbot resolve`. This is the desired outcome.
+
+If the concern has still not been resolved, there will typically be a period of deeper discussion. The goal is to [find common ground](./making_decisions.md#design-axioms), either by mitigating it directly or by side-stepping it via a subset of the design that still achieves the major goals.
+
+### Challenging a concern
+
+If deeper discussion does not reach a solution, a [lang team member](#definitions) can challenge a concern. This indicates that they feel they understand the concern and do not agree it is a problem.
+
+Challenging a concern is done by scheduling a meeting in which the lang team reads and discusses a summary of the concern and the subsequent discussion. At the end of this meeting, the concern will either be *sustained* (meaning that progress is still blocked) or *resolved* (meaning that final-comment-period can continue, assuming there aren't other concerns to be resolved).
+
+Sustaining a concern requires [1/4 of the lang team](#doing-the-math) to agree to sustain; this number includes the person who raised the concern, if they are a member of the lang team and not an advisor. Members can agree to sustain either because they with the concern *or* because they feel more time is needed for discussion.
+
+*Note:* The document to be read during the meeting will ideally be prepared by both the person raising the concern and the people challenging it so that it fairly represents both points of view. The document should include a
+
+1. summary of the concern and discussion;
+2. coverage of possible mitigations, changes, or subsets that were considered and their pros/cons
+
+
+## Doing the math
+
+Given a team of N>=4 members, the actual threshold `R` for approving a decision is `R = round(N * 2 / 3)`. The threshold `S` for sustaining a concern is `floor(N / 4)`. So e.g...
+
+| N   | R   | S   |
+| --- | --- | --- |
+| 20  | 13  | 5   |
+| ... | ... | ... |
+| 12  | 8   | 3   |
+| ... | ... | ... |
+| 9   | 6   | 2   |
+| 8   | 5   | 2   |
+| 7   | 5   | 2   |
+| 6   | 4   | 2   |
+| 5   | 3   | 2   |
+| 4   | 3   | 2   |
+
+If the team has 3 members or less, all members must agree to all decisions and concerns cannot be challenged. Really y'all need to recruit some new members at that point.

src/decision-making.md

@@ -0,0 +1,28 @@
+# Decision making
+
+This page documents our decision making process.
+
+## Our goal
+
+We want the ability to make designs that feel fresh, bold, and innotative. We do not want Rust to feel like it has been "designed by committee", with all the interesting bits smoothed down.
+
+We also want designs that meet Rust user's needs and live up to Rust's ethos of reliabile, performant, accessible code.
+
+These two goals can be in tension. The former pushes us to empower individuals. The latter pushes us to validate designs broadly. We use this decision making process to guide us in balancing those tensions.
+
+## Design axioms
+
+Our decision making process axioms are rules that we follow to help us achieve our goal. We try to satisfy them all, but if they come into tension, we prefer items that appear first in the list.
+
+* **No new rationale**. We make decisions only after the rationale have been presented publicly and all relevant stakeholders have had a chance to present counterarguments.
+- **Not afraid to do the right thing**. At the end of the day, we have to do what we feel is *right*. Sometimes this means breaking with the tradition and precedent set by other languages. Sometimes it means taking a socially uncomfortable stance (but always with respect).
+- **Find common ground**. It's good to break up designs into small pieces and proceed step by step. But be sure that each piece solves an end-to-end problem on its own.
+- **Trust each other**. Lang team members are expected to have demonstrated sharp instincts, humility, and the ability to hear and understand others. Sometimes you have to put your doubts aside and trust the others on the team. 
+- **Treasure dissent**. When someone raises a concern, we take it as an opportunity to improve the design, not an obstacle to be overcome. We invite people to elaborate and make sure we understand what's motivating them before we decide how to respond.
+
+## Processes
+
+We divide decisions into two categories:
+
+* [Reversible decisions (aka, 2-way door)](./2-way-door.md), used for [starting experiments](./how_to/experiment.md) and other decisions that don't make a promise to our end users. Reversible decisions follow a "champion" rule, which means that just one person on the team has to be in favor for the decision to go through; others on the team present concerns as a way to help make sure the champion is aware of them.
+* [Consensus decisions (aka, 1-way door)](./consensus.md), used for [stabilization decisions](./how_to/stabilize.md) and for RFC approvals. Consensus decisions require everyone on the team to sign off. The decision cannot be finalized if there is a blocking concern backed by 2 or more team members.