new decision process #326
Open
new decision process #326
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tmandry
reviewed
May 2, 2025
Comment on lines
+11
to
+14
| * **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. |
There was a problem hiding this comment.
Suggested change
| * **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. | |
| * **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. |
src/consensus.md
Outdated
|
|
||
| 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/3 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. |
There was a problem hiding this comment.
Suggested change
| Sustaining a concern requires [1/3 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. | |
| Sustaining a concern requires [1/3 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 agree with the concern *or* because they feel more time is needed for discussion. |
|
|
||
| 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. |
There was a problem hiding this comment.
Suggested change
| We also want designs that meet Rust user's needs and live up to Rust's ethos of reliabile, performant, accessible code. | |
| We also want designs that meet Rust users' needs and live up to Rust's ethos of reliabile, performant, accessible code. |
tmandry
reviewed
May 3, 2025
src/consensus.md
Outdated
|
|
||
| ## Doing the math | ||
|
|
||
| Given a team of N>=4 members, the actual threshold `R` for approving a decision is `R = floor(N * 2 / 3)`. The threshold `S` for sustaining a concern is then `N - R`. So e.g... |
There was a problem hiding this comment.
This formula is nice because it's simple, but I actually prefer something like this for S:
S = max(2, round(N / 3))
My reasoning is that we shouldn't lean into making it harder to sustain a concern when we add a person to the team. I'm looking at the transition from N=6 to N=7 here. Sometimes the numbers are going to work out that way, but this formula basically says "if you don't have enough to increase the consensus threshold, you have to increase the concern threshold", and that feels too eager.
I would still pick floor for R because as the number of members increases, the chance that one or more are unavailable at a given time goes up. Requiring 5 out of a 7 member team for simple decisions feels a bit aggressive. Of course, if the decision is not simple and could use input from someone not present, I would still expect someone to delay by filing a concern.
I would also be fine dropping the max; it just means concerns can't be challenged at N=4.
|
Overall this looks great to me. I really like how the axioms support the process and vice versa. |
|
Thinking on this more, I like the idea of having the threshold to sustain a concern be something other than |
After some discussion with tmandry, I realized that S + R do not have to add up to N. In fact, it seems good to have a bit of a "gap" such that it's easier to sustain a concern than it is to push something forward, allowing for "abstains".
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello @rust-lang/lang. This is a slightly revised variant of the decision making process that we discussed in our Mar 12 design meeting and which I've subsequently discussed with all of you at various points. This replaces the previous decision making content, which was added by @joshtriplett on #113.
Highlights of this new process
The 2/3 and 1/3 thresholds align with our current values (3 to approve FCP, 2 to sustain a concern). However, I wanted ratios that would scale as we (optimistically) grow.
I've not included the material on champions here. I think it supports this process well but it's orthogonal. I'll add it in a follow-up PR, this was meant to be focused on decision making.
I intend to move to fcp this PR, but I'll wait a bit for suggestions or feedback. I know that in our last meeting there were some concerns raised about the new process making it too easy to overrule concerns. I've tried to address those by explicitly noting what the summary document should contain and emphasizing in the axioms and elsewhere that we prefer to "find common ground". At the same time, the chief axiom is to not be afraid to do the right thing (well, the second axiom, after "no new rationale"), and I think that in the end sometimes the right thing is to move forward.