Resolution: "Recursive block" concern

[nikomatsakis]

Resolution: Recursive Blocking

This is a resolution document for the "recursive blocking" concern raised in #360.

Summary of the concern

Should someone who raised a concern be able to block an FCP that resolves their own concern? The current draft says no - the concern-raiser must convince another team member to block on their behalf.

Two views on reaching strong designs

Rust teams have always operated by consensus, not by voting. Consensus-based decision making aims to avoid some of the failure modes of voting:

The advantage of consensus-based decisions as compared with majority rule voting is that it avoids a fundamental problem often associated with voting. Voting may unintentionally result in a split or division in a group, a satisfied majority and disgruntled minority, a sense of winners and losers. [..] If a proposal is deeply troubling to even one person, that concern is respected; if it is ignored, the group is likely to make a mistake.

— A Practical Guide for Consensus-Based Decision Making

However, consensus is not just one thing - there are many ways to structure a consensus process. Our de jure rules have always included release valves: RFC 1068 states that team leads can resolve deadlocks; our own docs require concerns to be seconded.

But our de facto process has been different. In practice, the right to block progress has been sacrosanct: any team member can raise a concern, and only that team member can withdraw it. We have never invoked the lead's tie-breaking power, and we have never required a concern to be seconded.

The question before us is whether to formalize this de facto practice - or to move toward a process where the team collectively decides when a concern has been addressed.

Common ground

Many Rust decisions are one-way doors that are challenging to change later. We're often evaluating hypotheticals and counterfactuals that we can't easily gather evidence about until after we've gone through the door.

The lang team is a small group of people (no more than 8) who work closely together and have established trust. The expectation is that when someone raises a serious concern, it won't be papered over - it will be engaged with genuinely. The dissenter may participate in the discussion thread, explain their concern in detail, and request a design meeting where they can prepare a document for focused discussion.

Both views agree on the following:

• Minority perspectives matter. We intentionally select for high-judgment individuals who cover a wide range of perspectives. In any particular case, a given perspective may be represented by only 1-2 people. Each concern is an opportunity to learn new insights.
• The cost of indecision is not zero. Choosing not to decide is still a choice with consequences.
• Blocking comes with responsibilities. Concern-raisers should work to externalize their concerns, evaluate potential resolutions, and seek resolution rather than deadlock.
• We can't achieve perfect foresight. Some constraints only emerge after shipping, regardless of how much deliberation we do beforehand.

Where the views differ is in how they weigh the tradeoffs. In View A, the dissenter may block the resolution; it cannot proceed without their agreement. In View B, the resolution proceeds if (a) enough of the team checks their boxes and (b) no other team member raises a concern. Both views agree that if someone else chooses to block, that is fine and a meaningful signal.

View A: Treasure dissent

Emphasis: the risk of making a misstep.

The process of reaching full-team consensus produces results we can feel more confident in. We weigh correctness higher than velocity, and treasure dissent when it arises. A decision without full consensus is a decision that cannot reach our confidence threshold to proceed.

Given the stakes of getting one-way-door decisions right, serious doubts from any team member should give us pause. Full consensus wouldn't scale to a large group, but it works for a team of around 6-7 trusted people. Beyond that size, we should spin up focused subteams anyway.

The risk of this view: We move too slowly, or get stuck entirely.

The mitigation: The burden falls on the dissenter. They must weigh carefully: is this really worth blocking? After thorough discussion, continuing to hold a blocking concern is a serious act. Anyone maintaining a block should explicitly confirm: is the risk high enough that "deciding to do nothing" is an acceptable outcome?

View B: Perfection is a process

Emphasis: the cost of not deciding and the limits of pre-ship deliberation.

The cost of indecision is real: lost momentum, missed opportunities, and the disenchantment that comes when people can't count on making progress.

What's more, consensus doesn't prevent the mistakes we should fear most. Many mistakes arose from decisions where nobody raised a concern at all.

Finally, blocking on consensus can sometimes paradoxically prevent us from solving the problem in a mutually satisfactory way. If consensus hasn't been reached after extensive discussion, it may be that what is needed is to ship something that unblocks the most critical use cases, even if it closes off some others. Shipping brings an influx of new experiences, new people, and new ideas that can reveal a path forward that wasn't under consideration before.

The risk of this view: We move when we should have stood still, or ship more than necessary.

The mitigation: The burden falls on the team. Particularly when the person who raised the original concern is still unsatisfied, the team should ask: can we ship something more minimal? What options exist to course-correct later? Is there a two-way door version of this decision?

The crux of the debate

Both views acknowledge they carry risk. Both have mitigation strategies. The difference is who bears the burden and what question they're asking.

Let us assume that there has been significant discussion and there is a proposal to move forward, but the dissenter that raised the original concern is not satisfied:

• Under View A, the dissenter must decide if their concern is serious enough to be worth blocking forward progress. The team cannot proceed if the dissenter decides it is.
• Under View B, the rest of the team must ask, "Have we engaged genuinely, and can we course-correct if we are wrong?" They can proceed if they all agree the answer is "yes", even over the dissenter's objection.

Put differently: when, after thorough discussion, a single team member remains unconvinced - which way do we tilt? View A tilts toward the dissenter's judgment. View B tilts toward the team's collective judgment.

Proposed resolution

Do not add recursive blocking. The person who raised a concern cannot block the FCP to resolve that concern.

However, add process scaffolding that encouages genuine engagement with concerns, particularly in cases where the concern-raiser does not sign off on the resolution:

• Template for resolution write-ups, including specific reflection questions (see the FAQ for details)
• Option for concern-raiser to request a design meeting before final decision is complete (where they provide the document)

Rationale: Niko's "vibe check"

I favor View B: perfection is a process. For me, it comes down to two things.

First, View A underestimates the cost of consensus. Yes, debate improves quality, but at the cost of time and morale, and with sharply diminishing returns. In my experience, we map out the problem space fairly quickly. What follows is protracted rehashing of the same points that can be extremely frustrating.

Once the space is mapped, I trust the team as a whole to decide whether we should (a) move forward with a subset, (b) pick a direction, or (c) do nothing at all. With 100% consensus, a single person can have undue influence on that decision, and that doesn't feel right to me.

Pushing a new feature over the line is a lot of work and people need to know they can make progress in a reasonable period of time. If a single team member can block the process indefinitely and nobody can do anything about it, then the team cannot make that promise. And when people can't count on progress, they become disenchanted with the process entirely.

Second, View A exaggerates the cost of mistakes and consensus's ability to prevent mistakes. I believe strongly in stability without stagnation. We've shown that just because we make strong backwards compatibility guarantees doesn't mean we can't evolve the language. And it's a good thing, too, because the reality is that making mistakes is just part of the process, and 100% consensus doesn't prevent it.

We have walked through many one-way doors without anyone raising an eyebrow, much less a concern: think of things like "every value can be moved". Sometimes I think consensus can even make it harder for us to prevent mistakes, as protracted debate around one issue (say, whether to write await x or x.await) exhausts everyone so much that other weighty questions get short shrift.

In those cases where we made decisions that were clearly "wrong", for the most part, I don't regret it. Take the "Leak-pocalypse": we shipped 1.0 without guaranteed destructors, and I'm glad we did. The fixes we had at the time (focused on 'static) weren't the right ones anyway. We're in a better position now to get the design right, even with backwards compatibility constraints, precisely because we shipped something. That let us see where the lack of guaranteed destructors really hurts us and also gave us more time to invent alternatives.

--nikomatsakis

Proposed design axioms

This resolution suggests two design axioms for our decision-making principles:

Trust the team to decide, trust the champion to design. The team provides feedback, but we trust champions to weigh and balance that feedback into a coherent design. We trust the team to collectively make the final decision, not any individual.

Perfection requires progress. You can't know everything upfront - the full set of constraints only reveals itself as you take steps. Step carefully but deliberately into the future, confident that we can course-correct when we learn more.

FAQ

What is your proposed template for concern resolutions?

You've been reading it. I would start with a template like this:

# Resolution: *problem title*

## Summary of the concern

* Explain what's going on, give context

## Alternatives on the table

* Explain the design
* Cover common ground
* Present the alternatives 

## The crux of the debate

* Crystallize the key decision to be made

## Proposed resolution

* What you propose to do: short and to the point
* Details can come in the FAQ

## Rationale

* Your explanation of how you arrived at that
* This should be personal and draw on your experience
* Show how you are balancing the concerns

## FAQ

* Elaborate here
* Answer the standard FAQ (or put N/A if they don't apply)
    * What doors are closed with this decision? Can it be reversed? If so, how?
    * What would convince you that you were wrong about this decision?

What doors are closed with this decision? Can it be reversed? If so, how?

This decision is reversible. We could amend the decision process to add recursive blocking through a future FCP. The process scaffolding (template, design meetings) would remain valuable either way.

What would convince you that you were wrong about this decision?

For me (nikomatsakis): If we saw a pattern where people were following the "letter of the law" rather than the spirit - quickly moving to resolve concerns without deeply engaging. The process scaffolding is meant to prevent this, but if it doesn't work in practice, the underlying mechanism may need to change.

Signs that should prompt reconsideration:

• Repeated "Cassandra concerns", where the concern was dismissed but proven right in hindsight
• Shallow rationale used to address concerns
• Team members feeling like there is no point in raising a concern because "the team won't listen anyway"

What wouldn't change my mind: concerns regularly being resolved without the concern-raiser checking their box. That alone doesn't bother me. Decisions will not always go the way we prefer - consensus is not unanimity.

[nikomatsakis]

@rust-rfcbot merge

[nikomatsakis]

@rfcbot merge

[rust-rfcbot]

Error encounted:
Provided team `` is invalid

[nikomatsakis]

I recommend the rest of the team posts their "vibe check".

[nikomatsakis]

@rfcbot merge lang

[rust-rfcbot]

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

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

Concerns:

• hear-from-josh resolved by Resolution: "Recursive block" concern #365 (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]

@rfcbot concern hear-from-josh

This issue proposes to resolve a concern formally raised by @nikomatsakis in #360 (comment), but the underlying concern is one that @joshtriplett holds. I want to hear from Josh that, in his view, @nikomatsakis' statement of the concern matches the actual concern (or what the diff is if not) and that @nikomatsakis' analysis of the tradeoffs fully comprises those considerations that Josh would raise (and again, if not, what should be added or reframed).

[nikomatsakis]

@traviscross I don't think you need to raise a concern. @joshtriplett is perfectly capable of responding himself.

I have deliberately set this up this way so as to remove the question of "recursive blocking" from this particular decision -- that is, this is my concern, so @joshtriplett has the potential to block if he so chooses. I don't particularly want him to, I'd rather he makes his case and allows the decision to go forward if enough others agree, but "procedurally" he could raise a concern whichever view we adopted.

I reviewed many drafts of View A with @joshtriplett and did my best to ensure it represented "the canonical version" of his POV -- that is, @joshtriplett's actual expression was closer to the union of the "Common ground" and "View A". As I wrote earlier, this was also because I wanted to weigh it and think it over more carefully.

That said, as I wrote above, I encourage everyone to give their own Vibe Check (as I did). I don't necessarily expect View A or View B to "exactly" represent anyone's POV, you can have your own balance or your own additions to add.

One nit I would add though is that I do not intend to "reframe" the document unless there is something major. I would be happy instead for each person who has a different framing to leave it here as a comment, or I can add it verbatim as a FAQ or another Vibe Check to the OP if desired. Otherwise I think there is a form of "filibuster by another name" in which we iterate endlessly on the main document framing.

[nikomatsakis]

Two additional points:

Part of my concern with a "by proxy" concern at this point in the process is that I've observed that having a pending concern early in the process has the side-effect that others don't bother to register their thoughts until the concern is resolved. I am interested to hear from lang-team members and advisors on their opinions. If we were entering or deep into FCP and still you felt we had not heard enough directly from Josh or anyone else for you to feel comfortable going forward, that'd be a different matter.

Second, as I said, I did set this up intentionally so that whichever way we went on this particular matter it didn't affect this FCP. That said, I do not yield the point that, as far as I'm concerned, our rules do not permit a single person to block. I recognize that we've not had a formal means of exercising that option before and thus there is room for multiple takes on this.

[tmandry]

Looking at the resolution and the context shared by @nikomatsakis, I think he has engaged with the concern earnestly. I appreciate the effort that evidently went into that, both from him and from @joshtriplett in explaining his position. The document seems written deliberately to bring out the best of each side and weigh them honestly, and I hope to use it as an example going forward.

As for my vibe check, I am in favor of the resolution. To me, this is about taking the existing social norms of the team when it is operating in a healthy way and formalizing them, making the process more fair and transparent for everyone who participates.

I don't think this will fix all problems with the way we make decisions. But it will provide an important correction mechanism for when one person on the team is missing perspective. And I want to emphasize that this is an expected condition we should plan for, rather than a personal failing.

I deeply respect my colleagues on the lang team and I think they all have stellar judgment. I also think none of us is perfect, and we all lack perspective at times. Sometimes the way to gain that perspective and share our own is through further discussion. At other times, protracted discussion imposes a serious cost on other participants and the project as a whole, and the right decision is to move on.

When discussions are challenging, I trust that the team will collectively make an effort to engage each others' concerns earnestly. I expect that at least one person in the majority will have the self-awareness to correct when they are not. While this is by no means guaranteed, risk and uncertainty are unavoidable in any case. I am more willing to rely on that collective judgment than I am willing to rely on every dissenting individual having self-awareness of when their dissent has run its course.

For me, that's really what's at the heart of this resolution: It admits fallibility of both the team and the individual, creating a balanced correction mechanism for each.

@rfcbot reviewed

[traviscross]

As for the concern above I filed in #365 (comment), the concern is mine. In #360 (comment), @nikomatsakis filed a concern that mirrors (unfiled) concerns that have been raised by @joshtriplett. This issue now proposes to resolve the filed concern, and my understanding and expectation is that, in doing that, we intend to resolve @joshtriplett's concerns as well -- i.e. we mean for this resolution to preempt substantially similar concerns.

Given that, I'd like some assurance that we're engaging with a complete articulation of these concerns. While I have every confidence that @nikomatsakis made every effort to do this, at the end of the day, the concern has been @joshtriplett's. I want to be sure we hear him. I would not like to give a final vibe, check a box, or see this go into an early FCP only for Josh to reply that what we reviewed did not fully embody his concern and so we were failing to actually engage with it.

That's the concern. I'll resolve it when @joshtriplett either gives this assurance or fills in any missing details or framing, or otherwise after a reasonable interval.