Revise decision process: champion vs FCP decisions #360
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
|
@rfcbot fcp merge Hi folks, I'm proposing merge here, this process has been vetted with a number of you, but I'd welcome discussion (natch). (let me try that again...) |
This comment was marked as outdated.
This comment was marked as outdated.
|
@rust-rfcbot fcp merge T-lang Hi folks, I'm proposing merge here, this process has been vetted with a number of you, but I'd welcome discussion (natch). |
|
I can't tell what's going on -- but anyway, it's nominated. |
Replaces the previous "reversible/consensus" framing with "champion/FCP" decisions based on PR feedback. Key changes: - Champion decisions: triage nomination instead of rfcbot poll, any team member can request FCP escalation at any time - FCP decisions: new concern resolution process with dedicated issues and resolution template, original concern-raiser cannot block resolution - Two-pizza team (4-8 members): removes ratio formulas - Updated how_to pages to use new terminology 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
traviscross
force-pushed
the
decision-process-2
branch
from
08ed043 to
f1af0ef
Compare
|
Currently reviewing. One quick note: I'm sad to see this removing the proposed rustbot-based mechanism, which seemed like a vast improvement insofar as it removed the problem of having to cancel and restart a decision to change its direction. That mechanism also allowed for tracking multiple possible preferred outcomes (e.g. variants of a solution), and the history of changes to each person's position. Is there some incompatibility between this proposal and that mechanism? (That mechanism built upon process that needed further improvement, but the mechanism itself seemed sound.) |
Co-authored-by: Travis Cross <[email protected]>
|
Having now reviewed this carefully, I think this makes a lot of sense. In particular, I appreciate that it's simple. As a team, we're good at reviewing documents, proposing a way forward, and then checking for consensus on that. The process proposed here leans into that, and I think that will help us be successful with it. Two things surprised me a bit, which I'll mention. After sitting with them, I decided that they're OK. One, the FCP to resolve a concern 1) does not require a supermajority and 2) does not first require a design meeting if the person who raised the concern wants it. Theoretically, then, a concern could be summarily dismissed, with a stated rationale but no further discussion, by a bare 3/5 majority who had already wanted to move forward. If that were to become our practice, that would certainly be concerning, but I'm not worried about that happening. If a member reasonably wants a design meeting to be heard out, I can't imagine us not making room for that -- I'd expect at least one of us would file a concern if needed. It feels OK to lean on our rapport and social expectations in order to keep the process simple. Similarly, while the resolution FCP could sneak by on 3/5, that still leans on no other member filing a concern. While there is some difference between someone actively filing a concern and just passively not checking a box, the difference seems small enough in this context to not be concerning as long as it's never used tactically (i.e., by the FCP period overlapping a time when one member is away). Again, it seems safe to rely on our social mores. Whatever my views on the underlying issue, I'd be inclined to file a concern on a resolution if someone who might conceivably support the concern is temporarily away. Two, the proposal suggests that all champion decisions should be nominated. While we've been doing this when starting an experiment, to build context and uncover problems early, champions make a number of other, subtler decisions when guiding along an experiment that we haven't been nominating. One way to look at this would be to say that these kinds of decisions -- where the champion is acting as a participant in the design process -- aren't what we mean by champion decisions. Another way would be that, indeed, perhaps more of these incremental design judgment calls should be nominated for context but not consensus. Both of these seem right to me, and I trust that we'll work out some reasonable balance on this. @rfcbot fcp merge lang |
|
Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
rust-rfcbot
added
proposed-final-comment-period
disposition-merge
For me, the fact that this isn't currently how we're operating is a good enough reason to remove it. In addition, given the amount of time that has passed, I'd expect that to begin operating in this manner would require a new proposal and consensus. |
Co-authored-by: Travis Cross <[email protected]>
tmandry
left a comment
tmandry
left a comment
There was a problem hiding this comment.
I'm aligned with the overall direction, and I think the simplification compared to earlier proposals looks positive. Clarifying and refining our decision process is very high-leverage work but often thankless work, so a big thanks to @nikomatsakis for pushing this forward.
I went through carefully and added comments; mostly nitpicks, but some that might warrant further discussion.
|
|
||
| If you are an experienced Rust contributor who would like to start an experiment in-tree, the process is as follows: | ||
|
|
||
| * Write-up a description of the problem you are trying to solve and the general shape of the solution you want to work on. Discuss it on Zulip or elsewhere to find a **lang-team liaison**: |
There was a problem hiding this comment.
I would like to migrate this entire section from using the term "liaison" to "champion". I think we use the terms interchangeably and one noun is better than two.
The alternative would be using two different nouns to clearly distinguish the project goal role from the experiment role. But then we should stop calling the decisions "champion decisions". I think the same person should be filling both roles so I don't see a need for this.
| If you are an experienced Rust contributor who would like to start an experiment in-tree, the process is as follows: | ||
|
|
||
| * Write-up a description of the problem you are trying to solve and the general shape of the solution you want to work on. Discuss it on Zulip or elsewhere to find a **lang-team liaison**: | ||
| * The liaison is the connection to the lang-team. They can check in with you from time to time to see how the work is going and relay those updates to the lang-team (of course, you're always welcome to join meetings yourself too!). They can also help to discuss problems that arise. |
There was a problem hiding this comment.
Include who is eligible to be a lang team champion. Suggested wording (first line unchanged):
| * The liaison is the connection to the lang-team. They can check in with you from time to time to see how the work is going and relay those updates to the lang-team (of course, you're always welcome to join meetings yourself too!). They can also help to discuss problems that arise. | |
| * The liaison is the connection to the lang-team. They can check in with you from time to time to see how the work is going and relay those updates to the lang-team (of course, you're always welcome to join meetings yourself too!). They can also help to discuss problems that arise. | |
| * Members of lang and lang-advisors are eligible to champion an experiment. |
| * Once you've found a liaison, open a PR adding a new feature gate to the compiler and create an associated tracking issue. | ||
| * The PR and tracking issue should include a write-up documenting the motivation and outline of what they are trying to achieve. | ||
| * The PR and tracking issue should include a write-up documenting the motivation and outline of what they are trying to achieve. | ||
| * The feature gate should be marked as 'experimental', so that users get warnings if they try to use it. This flag has to stay until an RFC is accepted, even if the implementation is in good shape. |
There was a problem hiding this comment.
Note that probably deserves its own issue: We have not followed this. We have a lint for incomplete features, which describes the state of the implementation, but not a lint for experimental features. e.g.
warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes
--> src/lib.rs:1:12
|
1 | #![feature(generic_const_exprs)]
| ^^^^^^^^^^^^^^^^^^^
|
= note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information
= note: `#[warn(incomplete_features)]` on by default
In my opinion, if we start enforcing this for real, the real benefit would come when we start moving features back into an experimental state after we consider their RFC to have "timed out". Once we have a clear way of marking the true status, the lint gives us a clear way of communicating it.
Before that it functions as a sort of nudge for the owner to move things along to the RFC phase, which has value but is less obviously worth the trouble.
There was a problem hiding this comment.
Separating the two has been requested a lot on the compiler side, I'd like that to happen.
There was a problem hiding this comment.
@Nadrieril Can you say more? Do you mean between a compiler-team project goal champion and a reviewer? Or is compiler requesting that lang separate the roles on its side?
There was a problem hiding this comment.
Sorry, I meant "the ability to distinguish features that aren't complete but are RFCd from features that aren't even RFCd"
|
|
||
| ### FCP escalation | ||
|
|
||
| Any team member can request FCP escalation at any time—during the triage meeting or later. This converts the decision to an [FCP decision](./fcp-decisions.md), which follows the full FCP process. |
There was a problem hiding this comment.
What is an example (hypothetical or not) of this being used in the way you intend?
Alternative framing: If we didn't have this, what could go wrong?
(I have some thoughts, but am curious to hear yours first.)
| * The PR and tracking issue should include a write-up documenting the motivation and outline of what they are trying to achieve. | ||
| * The feature gate should be marked as 'experimental', so that users get warnings if they try to use it. This flag has to stay until an RFC is accepted, even if the implementation is in good shape. | ||
| * The lang-team liaison will "second" the PR, starting an FCP. Once the FCP completes, the PR can land and implementation work begins (always gated under the new feature gate). | ||
| * The lang-team liaison will [nominate](./nominate.md) the PR for discussion at a triage meeting. This is a [champion decision](../champion-decisions.md)—if no one requests FCP escalation, the experiment can proceed. |
There was a problem hiding this comment.
| * The lang-team liaison will [nominate](./nominate.md) the PR for discussion at a triage meeting. This is a [champion decision](../champion-decisions.md)—if no one requests FCP escalation, the experiment can proceed. | |
| * The lang-team liaison will [nominate](./nominate.md) the PR for discussion at a triage meeting. This is a [champion decision](../champion-decisions.md)—if no one requests FCP escalation in the meeting, the experiment can proceed. |
For clarification
|
|
||
| #### The resolution template | ||
|
|
||
| A resolution must include: |
There was a problem hiding this comment.
| A resolution must include: | |
| A resolution proposal should go in a comment on the concern issue, and must include: |
|
|
||
| If the concern is not withdrawn, someone (e.g. the document author) can propose a **resolution**. This is a more formal process that ensures concerns are genuinely engaged with. | ||
|
|
||
| #### Creating a concern issue |
There was a problem hiding this comment.
I think this should go under the "raising concerns" section rather than "resolving concerns". Otherwise it implies that the only reason to open an issue if you want to file a formal resolution, which I don't think is the intention.
There was a problem hiding this comment.
There is certainly a degree to which I'm not actually expecting that we'll file separate issues for the vast majority of our concerns -- those that are uncontroversial within the team. That does suggest that the issue may be created more lazily.
There was a problem hiding this comment.
I'm fine with creating issues lazily. Should we leave that decision to team members then? People outside the team who disagree can leave a comment on the original thread, and we'll decide whether to move that to a separate issue.
I still think the structure is a bit weird, but I'll leave it up to @nikomatsakis to do what he thinks is best.
|
|
||
| * Starting a [lang-team experiment](./how_to/experiment.md) | ||
| * Closing an RFC or issue that is clearly not going to be accepted | ||
| * Other lightweight decisions that don't make a durable commitment |
There was a problem hiding this comment.
| * Other lightweight decisions that don't make a durable commitment | |
| * Significantly changing an existing experiment's scope or goals | |
| * Other lightweight decisions that the team needs to be aware of, but that don't make a durable commitment |
| * Starting a [lang-team experiment](./how_to/experiment.md) | ||
| * Closing an RFC or issue that is clearly not going to be accepted | ||
| * Other lightweight decisions that don't make a durable commitment | ||
|
|
There was a problem hiding this comment.
| Note that many decisions made over the course of an experiment do not require a formal champion decision. Here are examples of decisions that do **not** require nomination: | |
| * Removing or sunsetting an experiment for reasons outside the lang team's direct control | |
| * Cutting scope or focusing on a particular sub-problem | |
| * Pursuing a particular direction in line with the original experiment's goals | |
| * New constraints you've learned as part of exploring the design space | |
| Note that all of these should still appear in a champion's regular updates to the team so that concerns can be surfaced. |
|
|
||
| **Important:** The person who raised the original concern cannot block this FCP. They can (and should) comment on whether the summary accurately represents their concern, but their only path to blocking is convincing another team member that the resolution is inadequate. | ||
|
|
||
| Other team members can raise new concerns on the resolution, or request a design meeting for deeper discussion. |
There was a problem hiding this comment.
This should clearly state whether advisors can raise concerns on the resolution.
Given the text above, I infer that the answer is no:
but their only path to blocking is convincing another team member that the resolution is inadequate
If the answer is yes, that should be changed to say "another team member or advisor".
To me the actual answer doesn't matter as much, I just want the docs to be clear on what our process is.
There was a problem hiding this comment.
#360 (comment) by @joshtriplett
One quick note: I'm sad to see this removing the proposed rustbot-based mechanism, which seemed like a vast improvement insofar as it removed the problem of having to cancel and restart a decision to change its direction. That mechanism also allowed for tracking multiple possible preferred outcomes (e.g. variants of a solution), and the history of changes to each person's position.
Is there some incompatibility between this proposal and that mechanism? (That mechanism built upon process that needed further improvement, but the mechanism itself seemed sound.)
Moving to a review comment to manage the discussion threads better.
There was a problem hiding this comment.
#360 (comment) by @traviscross
For me, the fact that this isn't currently how we're operating is a good enough reason to remove it.
In addition, given the amount of time that has passed, I'd expect that to begin operating in this manner would require a new proposal and consensus.
There was a problem hiding this comment.
I agree with what @traviscross said here. Having a documented decision process that we don't use on our website is extremely confusing.
I think there are good ideas in the document, but it predates me or @traviscross joining the lang team. Given both the membership changes and how much it seems like we have learned about managing the decision process, it would need to go through another round of review before becoming the way we operate.
To make sure we don't repeat the mistake of documenting a process we don't use, I would keep any process that depends on speculative rfcbot features in a separate design doc or RFC until it has been implemented and we are ready to start using it.
There was a problem hiding this comment.
Valid that we shouldn't have documentation that doesn't match our process, but I think we should move to that process, so we should revisit it rather than letting it die.
|
@rfcbot concern mull-over-blocking Until we talked in the meeting today, I hadn't thought about the potential impact of just having the second FCP on concerns. In other words, I'm filing this concern to give me a minute to think over whether I'd prefer to allow "recursive blocking" or not. I'd like to hear others' thoughts too; I'll try to post up the considerations as I see them in a bit when I get a chance to invest in writing. |
|
If we had recursive blocking, I expect I'd never do it. I'm curious what other lang members and advisors think. I'll raise and poll this on Zulip. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as resolved.
This comment was marked as resolved.
6 participants
This replaces the previous decision-making docs based on feedback from PR #326.
Key changes
Champion decisions (replaces "reversible decisions")
@rfcbot pollFCP decisions (replaces "consensus decisions")
Other