Revise decision process: champion vs FCP decisions

book.toml

@@ -39,3 +39,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/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)
+  - [Champion decisions](./champion-decisions.md)
+  - [FCP decisions](./fcp-decisions.md)
 - [Becoming and being a lang-team member](./membership.md)
   - [Lang-team leads](./leads.md)
 - [Chat platform](./chat_platform.md)
@@ -28,5 +28,5 @@
   - [Eager drop](./design_notes/eager_drop.md)
   - [Autoderef and autoref in operators](./design_notes/autoref_ops.md)
   - [Copy type ergonomics](./design_notes/copy_ergonomics.md)
-- [Roadmaps](./roadmaps.md)
-  - [Roadmap 2024](./roadmaps/roadmap-2024.md)
+- [Rationale](./rationale/README.md)
+  - [PR 360](./rationale/pr-360.md)

src/champion-decisions.md

@@ -0,0 +1,35 @@
+# Champion decisions
+
+Champion decisions do not represent team consensus. Rather, they indicate that *somebody* on the team is willing to champion an idea. We use them to begin experiments and for other decisions where we want to move quickly and iterate.
+
+## When to use champion decisions
+
+* Starting or stopping a [lang-team experiment](./how_to/experiment.md)
+* Closing an RFC or issue that is clearly not going to be accepted
+* Significantly changing an existing experiment's scope or goals (either cutting or expanding scope)
+* Opting to focus on a particular design direction and halt investigations of others
+* Adding a new constraint to the design that you've learned as part of exploring the design space
+* Other lightweight decisions that you'd like the team to be aware of, but that don't make a durable commitment
+
+## Process
+
+### For the champion (lang team member or champion)
+
+1. Write up your proposal on a GitHub issue or PR, explaining the decision and context.
+2. [Nominate](./how_to/nominate.md) it for discussion at a lang-team triage meeting.
+3. At the triage meeting, the team will discuss and raise any concerns.
+4. Consider the feedback. If team members expressed strong concerns, you should likely address those before proceeding.
+
+### Handling concerns
+
+When people raise concerns:
+
+* **Treasure dissent.** Engage with them and make sure you understand the concern.
+* Note concerns on the tracking issue as "unresolved questions" or things to explore—they shouldn't be forgotten.
+* Concerns don't *block* you from proceeding, but they may give you pause, particularly if they are shared by multiple team members.
+
+## For other team members
+
+* Your approval is not required for champion decisions.
+* If you disagree with the decision or think it's a bad idea, say so (constructively)!
+* For experiments, ask yourself: What are the "weak spots" that the experiment ought to probe? What information can we gather?

src/decision-making.md

@@ -0,0 +1,35 @@
+# Decision making
+
+This page documents our decision making process.
+
+## Our goal
+
+We want the ability to make designs that feel fresh, bold, and innovative. 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 users' needs and live up to Rust's ethos of reliable, 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 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 has 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 tradition and precedent set by other languages. Sometimes it means taking a socially uncomfortable stance (but always with respect).
+* **Find common ground**. When there is disagreement, look for solutions that address everyone's concerns. Break up designs into smaller pieces if needed. 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.
+
+## Two kinds of decisions
+
+We divide decisions into two categories:
+
+* **[Champion decisions](./champion-decisions.md)** are the preferred default. They are used for [starting experiments](./how_to/experiment.md) and other decisions where we want to move quickly. A single lang-team member or advisor can champion a decision; others can raise concerns, but cannot block. A champion decision does *not* represent team consensus—it represents only the champion's point of view. Any team member can request FCP escalation at any point—during the initial triage meeting or later—which converts it to an FCP decision. Once a champion decision has been escalated and FCP'd, it becomes durable in the same way as any other FCP decision.
+
+* **[FCP decisions](./fcp-decisions.md)** represent a significant commitment from the team. They are used for [stabilization](./how_to/stabilize.md), RFC approval, and other cases where we are making a promise to our users or taking a position we don't want to reverse lightly. FCP decisions require broader team sign-off and follow a formal process for resolving concerns.
+
+**When to use which:** Prefer champion decisions when possible—they have lower overhead and enable faster iteration. Use FCP decisions when the decision is significant enough that reversing it should require another FCP. The expectation is that an FCP'd decision cannot be reversed without some change in circumstances: new experience, new information, or a reasoned change of mind.
+
+## Team size
+
+The lang team operates as a "two-pizza team" of 4-8 members. This keeps the team small enough for high-bandwidth communication and trust, while large enough for diverse perspectives.