Revise decision process: champion vs FCP decisions

[nikomatsakis]

This replaces the previous decision-making docs based on feedback from PR #326.

Key changes

Champion decisions (replaces "reversible decisions")

• Triage meeting nomination instead of @rfcbot poll
• Any team member can request FCP escalation at any point
• Does not represent team consensus—only the champion's view

FCP decisions (replaces "consensus decisions")

• New concern resolution process: create a GitHub issue per concern, propose a resolution with a structured template (summary, changes, rationale)
• Original concern-raiser cannot block the resolution FCP; must convince another team member
• References design axioms for documenting rationale

Other

• Two-pizza team (4-8 members)—removes ratio formulas
• Defer to standard rfcbot thresholds

[nikomatsakis]

@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...)

[nikomatsakis]

@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).

[nikomatsakis]

I can't tell what's going on -- but anyway, it's nominated.

[joshtriplett]

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.)

[traviscross]

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

[rust-rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• mull-over-blocking resolved by Revise decision process: champion vs FCP decisions #360 (comment)
• unanimity resolved by Revise decision process: champion vs FCP decisions #360 (comment)

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.
See this document for info about what commands tagged team members can give me.

[traviscross]

One quick note: I'm sad to see this removing the proposed rustbot-based mechanism...

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.

[tmandry]

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.

[tmandry]

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.

[traviscross]

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.

[tmandry]

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.

[tmandry]

#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.

[tmandry]

#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.

[tmandry]

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.

[joshtriplett]

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.

[nikomatsakis]

@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.

[traviscross]

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.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nikomatsakis]

Noting for the record that prior to merge we should include @joshtriplett's dissent.

[nikomatsakis]

@rfcbot concern unanimity

Per TC's point, waiting for unanimity.

[joshtriplett]

Registering that I'd like to record a dissent on this one, and need to write one up. @nikomatsakis said he would add a note on that to the decision process.

(Ah, @nikomatsakis, we were writing up comments to this effect in parallel. :) )

[nikomatsakis]

@tmandry and I went through his proposed edits. We made several smaller changes and two notable ones:

• Champion decisions no longer have an "escalation path" to FCP. Champions are just empowered to make those decisions on their own (they are, after all, reversible).
• We decided to remove the "formal" ability for advisors to raise blocking concerns (those are now limited to team members). The advisor role is focused on championing. The expectation is that the team will "treasure the dissent" of an advisor, naturally, but they do not have a formal role in the dissent process. The rationale is documented in the PR itself in the new "rationale" section, but I'll quote it here:

The original design of the lang advisors permitted them to raise blocking concerns. This is largely ceremonial, as the lang team advisors consists of people for whose opinions the team has deep respect, and hence a concern raised by them would never be overcome lightly. However, we wished to give the team some procedural distinction to make membership meaningful.

Under the new process, we have instead chosen to give advisors the ability to champion designs. This is a more positive distinction than before, as it means they now have the ability to make champion decisions on their own and to drive new ideas forward.

We decided to remove their ability to directly raise blocking concerns as it did not fit with the new resolution system. In particular, there was no satisfactory answer to the question of whether a champion should be able to block resolution. If they can block resolution, then it means that the pool of people which can block an FCP becomes significantly larger than the 4-8 people on the lang-team. This in turn implies that the threshold for blocking resolution may need to be raised to a proportional measurement, which threatened the nature of the team as a deliberative, unified entity.

On the other hand, if advisors cannot block resolution, it gives rise to a "procedural hack" in which an advisor raises the concern and then a lang-team member blocks any attempt to resolve it. This seemed like a threat to the intended use of the process.

Overall we felt that the simplest solution was to say that advisors are given the power to champion, and members the power to block.

@joshtriplett I left a place for your dissent in the rationale.

[tmandry]

With the latest round of revisions I'm happy to check a box. Thanks @nikomatsakis for your effort here.

@rfcbot reviewed

[nikomatsakis]

@rfcbot resolve unanimity

With the latest commits which resolved the matter of advisors in a minimal way (blocking the resolution of a concern requires 2 team members, addressing the question of what "no recursive blocking" means if an advisor raises the blocking concern and not a team member) and @tmandry having checked his box, I'm resolving the unanimity concern. @joshtriplett has a space to add a dissent in a follow-up PR.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔