---
title: "Design meeting 2025-03-12: Lang-team champions and initiatives v3.0"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2025-03-12
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Design.20meeting.202025-03-12/with/505186333
url: https://hackmd.io/2mZ5LZ0uStiKJAT-KRvBwg
---

# Lang-team champions and initiatives v3.0

## Goal

* Define a structure that captures how features move through the lang team. Integrate this with project goals.
* Define named roles (champion, design owner, etc) that can clarify who is doing what and help us to budget time.
* Clarify process for handling concerns that are blocking FCPs that have reached quorum (and hence would otherwise proceed).

## Summary

### Organizational structure for tracking the work we are doing as a team.

* Track active **features**, corresponding to either experiments or accepted RFCs, on a [project board](https://github.com/orgs/rust-lang/projects/63/views/1). This project board is the "source of truth" for lang-team planning.
* project goals can be tied to features by adding the corresponding `F-foo` label
* We will **review updates** posted on features or project goals during triage/planning meetings.
* I'll update the script to scrape them from project goals, tracking issues, etc.
* Features that have lain fallow for long enough require an RFC "refresh"
* The code isn't necessarily removed, but to be stabilized the RFC will need to be re-opened and re-approved.

### Define named roles (champion, design owner, etc) that can clarify who is doing what and help us to budget time

* Define three roles tied up in a feature. Multiple roles may be filled by the same person.
* champion -- advocate for the idea within the lang team, socialize (must be on lang team or advisor)
* design owner -- drive design, decide what changes (if any) to make in responses to lang-team concerns or feedback. As a rule of thumb, the design owner is the one authoring the RFC and responding to feedback on the thread.
* impl owner -- drive impl, make impl decisions (can be anyone)
* Every project goal with non-trivial ask from lang team requires a champion.
* Starting an experiment or accepting an RFC requires a champion.
* Champions or design/impl owners may step back from pursuing a feature. In that case, the feature goes into an ambiguous state for a while; eventually the feature will require an RFC refresh.
* Expectations of a champion
* Champions are responsible for keeping the lang-team up to date and for knowing the feature well enough to answer questions from the lang team.
* Champions help design and impl owners to understand how seriously each piece of feedback needs to be considered (e.g., "that was just a suggestion" vs "no, that is a hard blocker we need to reckon with").
* Champions author updates on relevant tracking issues at least monthly (or ensure that an update is authored by the owner).
* Champions ensure lang-team is aware of decisions and design changes made along the way.
* Champions (typically) meet at least every two weeks with the owner/experimentor driving the work, presuming there is a separate person doing that.

### Process for handling concerns that are blocking FCPs that have reached quorum (and hence would otherwise proceed)

* Once an FCP has reached "quorum" (enough checkmarks to be in FCP):
* If there is a blocking concern (from a team member or advisor) that covers the design, a design meeting will be scheduled. The concern author is responsible for writing the doc.
* Sometime after the meeting, the RFC author or other owner will decide what changes (if any) they wish to make. If concern author is satisfied, they can remove the concern.
* If concern author is not satisfied, RFC author can poll the lang team. 1/3 of full team members, or 2 people, whichever is more, must support the concern or else we will move on. This number includes the person who originally raised the concern, if they are on the lang team proper.
* **NB:** Unlike previous proposals, champions have no particular role in the decision making process. That role is taken up by the RFC or proposal owner instead, which will often but not necessarily be the champion.

## Guide-level design

> *Documents the process for would be contributors.*

The lang-team process is centered around *features*. The term *feature* is applied generally; it doesn't always mean a "new feature" of the language, it could include refinements, redesigns, or even significant bug fixes.

### Feature milestones

Features go through four milestones on their way to becoming stabilized:

* *Experiment accepted*
* A *lang-team experiment* is a prototype implementation done in advance of having an accepted RFC. Experiments are only available if there is an experienced rustc contributor (typically a compiler team member) doing or supervising the implementation work.
* To be accepted, an experiment requires a lang-team champion to serve as its advocate ([see below](#champions-and-design-owners)).
* Accepted experiments do NOT imply team consensus. Team members can raise concerns that are to be addressed during the experiment.
* [Read more about how to propose an experiment here.](https://lang-team.rust-lang.org/how_to/experiment.html)
* *RFC accepted*
* The RFC for a feature describes its user-facing surface area. The RFC being accepted means that all major user-facing questions are resolved.
* To be accepted, an RFC requires a lang-team champion to serve as its advocate ([see below](#champions-and-design-owners)).
* Accepting an RFC requires that a quorum of team members have "checked their box" and there are no blocking concerns (see below).
* *Preview announced*
* A feature can be announced as *preview* when all the user-facing features behave as expected and the feature is ready for casual users to try it out. Currently preview features are announced with a "call for experimentation" on the Rust blog. In the future, we should consider exposing the feature gate for use on beta builds.
* Being code complete does not imply that the feature is ready to be stabilized; there may be critical bugs and the feature may lack reference material, rustfmt or IDE support, etc.
* *Stable*
* A feature is *stable* when it is available on stable.

You can view the features currently under development on our Project Board. Features are categorized by the milestone they have achieved; some of them are tagged as "Perma-Unstable", which means that these are features that are not intended for stabilization.

### Stalling out

Features that are not in a position to make progress are said to be **stalled**. This typically occurs when the champion or design/impl owner steps back from the feature. We use the "stalled" field on the board to indicate when a feature is stalled and what is needed to get it back up and going.

If features stalled for long enough (typically ~6 months to a year), we will mark them as needing an **RFC refresh**. This means that the feature has been stalled long enough that we don't want to approve it without reconsidering the design, as circumstances may have changed in the interim.

### Champions and design owners

Features should have an assigned **lang-team champion** (or just **champion**, for short). We distinguish the role of *champion* from the role of *design owner* -- both can be done by the same person, but they don't have to be:

* The *design owner* is the person who is making decisions about the design. They ultimately decide what changes to make to the design in response to feedback.
* As a rule of thumb, the person authoring the RFC is typically the design owner.
* The *champion* advocates for the feature within the language design team. Champions understand the design well and can answer questions about it. They collect feedback from the language design team and bring it back to the design owner for discussion.

Champions must be lang team members or advisors. Champions are required when creating a new feature (either by starting a new experiment or by accepting an RFC). Champions can step away later and that doesn't mean the feature is rejected; however, progress is likely to be slow until a new champion is found.

### Project goals

Project goals are the Rust project planning mechanism. They cover about 6 months of work. Project goals for the lang team are typically (but not always) tied to an active feature. They generally identify a specific set of tasks that will move the feature along towards the next milestone: for example, building out a prototype, authoring an RFC, completing the implementation, or writing a stabilization report.

**Every project goal requiring non-trivial work must have a lang-team champion.** This is because accepting a project goal is a commitment on the part of the lang-team to help this feature make progress; assigning a champion is our way of ensuring we make good on that promise. If we cannot find a champion with enough bandwidth, we will not be able to accept a project goal.

## Detailed design

> *Documents the process for lang-team members.*

### Tracking in-progress features

We track features using a Github project board:

https://github.com/orgs/rust-lang/projects/63/views/1

Each feature has a primary tracking issue. Those tracking issues are added to the above board and then annotated with the following metadata:

* *State*, one of the four states above or *Perma-Unstable* for features that do not currently have a path to stabilization;
* *Champion*, a string indicating the github username of the champion (if any);
* *Design owner*, a string indicating the github username of the design owner (if any);
* *Impl owner*, a string indicating the github username of the impl owner (if any);
* *Stalled*, an indicator of what it would take to restart the project
* needs-lang-team-champion -- indicates that getting this feature accepted would really require getting somebody on the lang team or advisors to champion it. This is used for complex issues.
* needs-design-owner -- indicates that there is someone who would like to champion the project but they need a design owner to do the heavy lifting (the champion field should be set).
* needs-impl-owner -- indicates that there is someone who would like to champion the project but they need a design owner to do the impl work (the champion field should be set).
* needs-rfc-refresh -- after enough time without progress, indicates that although an RFC was accepted, enough time has passed that we ought to resubmit the RFC (possibly with changes) for reconsideration.
* *we can add more in the future*

### Reviewing updates from project goals and features

During planning and triage meetings we will review the comments left on tracking issues. nikomatsakis will adjust the triage meeting script appropriately to automatically generate those summaries. Lang-team members can pose questions to the champion for the clarification. The champion should ensure that all relevant design decisions are reflected in a comment on the tracking issue (the champion doesn't have to *write* those comments).

### Decision process for moving through milestones

The decisions required for each milestone, and criteria to be considered, are as follows:

* *Accepting an experiment:* (2-way door)
* Requires a **champion** to nominate the issue for discussion.
* As this is not a 1-way door, blocking is not allowed but team members and advisors can raise concerns that must be addressed. Champions are encouraged to talk out strong concerns about the design's feasibility or desirability up-front to try and figure out what data would be helpful in making the case.
* *Accepting an RFC:* (1.5-way door)
* Requires an **FCP**. Once the RFC is accepted, it is considered "bad form" to relitigate design decisions covered in the RFC unless new data or design alternatives are available.
* The RFC specifies the user-facing aspects of the design. The goal is that all the RFC should have enough detail that it unblocks all work that must be done before stabilization (implementation, authoring of reference/spec material).
* *Preview announced:* (2-way door)
* Indicates that the feature is ready for experimentation by end-users. The feature must align with the description in the RFC. If it does not, a fresh RFC or amendment is expected.
* Requires the tracking issue to be nominated for team review.
* *Stabilization:* (1-way door)
* Requires an **FCP**. Once the RFC is stabilized, the feature is subject to the lang-team semver guarantees.

**Nomination.** Nomination is a lightweight mechanism we use for 2-way doors. The relevant PR or issue is nominated for lang-team along with a write-up by the champion or owner. The issue is discussed in a meeting to allow for people to raise concerns or comments that will be considered by the owner. Because these are 2-way doors, no formal decision is needed and blocking concerns are not relevant. However, as a courtesy, if someone is absent from a meeting and we know they are likely to have useful feedback, the champion should either reach out to them separately to discuss or wait for a meeting where they are present.

**FCP.** The Final Comment Period decision making process is used for 1.5- and 1-way doors. It requires a "quorum" of members to check their box and that there are no outstanding concerns. We have a process for resolving concerns described below.

### Raising and resolving FCP concerns

FCP begins with a series of checkboxes, one per team member. Lang team members can indicate their agreement with the proposal by leaving a comment like `@rfcbot reviewed` or checking their boxes. Alternatively, members or advisors can raise a concern with the `@rfcbot concern` command. Concerns pause the process until they are resolved.

The FCP process ends when a quorum is reached (currently: 2/3 of members have checked their boxes) and there are no outstanding concerns. If the quorum is reached and there is an outstanding concern, or if a concern is raised after the quorum is reached, we have a standard process for resolving it:

* We schedule a design meeting to talk over the issue. The person raising the concern is responsible for authoring the document.
* After the meeting (either immediately or later), the design owner decides what changes they want to make in response to the concern (if any).
* The concern author can then decide if they are satisfied (in which case they resolve the concern) or not. If they are not satisfied, then the team is polled. If 1/3 of the team agree that more discussion is needed, then the FCP is canceled until it can be addressed.
* Team members do not need to agree with the concern -- they may simply feel that more investigation is needed before reaching a final decision.
* In general, team members should
* look favorably on concerns that preserve forwards compatibility as long as they don't sacrifice key use cases or add undue complexity for end users;
* look negatively on unsubstantiated concerns or concerns that relitigate questions that have already been resolved.

Note that the standard process is by no means mandatory. It's always fine for the champion (and/or design owner) to sync with the concern author offline and reach a conclusion.

### Deciding on champions for project goals and experiments

During project goal planning season, the lang team lead(s) will propose champions to all project goals under consideration and review those selections with the teams. Those champions must agree to serve in that capacity. It is expected that serving as champion implies meeting with the design owner at least every other week.

### Expectations of a champion

* Champions are responsible for keeping the lang-team up to date.
* Champions help design and impl owners to understand how seriously each piece of feedback needs to be considered (e.g., "that was just a suggestion" vs "no, that is a hard blocker we need to reckon with").
* Champions author updates on relevant tracking issues at least monthly (or ensure that an update is authored by the owner).
* Champions ensure lang-team is aware of decisions and design changes made along the way.
* Champions (typically) meet at least every two weeks with the owner/experimentor driving the work, presuming there is a separate person doing that.

### Reverting features

As a rule of thumb, when features have been stopped for over a year, the team should discuss the level of consensus. When an RFC has gone over a year without reaching preview state, it likely makes sense to revert the feature to experimental status or remove it altogether. People can re-open the RFC for fresh consideration later.

## Frequently asked questions

### Why do we assign champions to project goals?

Originally I wanted to assign champions to all active features but there are simply too many in-flight features for that to be realistic. Project goals are our existing mechanism for designating a subset of things that we actually plan to get done, so assigning champions to the active goals is a way of ensuring we make progress.

### Why split design owners from champions?

The idea was to emphasize that the person driving the design does not have to be a lang team member and to ensure that they are given adequate credit. Sometimes the line between design owner and champion is clear and other times a bit blurry, but that's ok. As a rule of thumb, the person authoring the RFC and doing the primary discussion on the RFC thread should be listed as the design owner.

### What if a design owner doesn't agree with a concern raised by the champion or a lang-team member or advisor?

The design owner is free to reject feedback or concerns -- but the lang-team is also free not to accept an RFC. There is tension here and that's a good, healthy thing. This is why we have the concern process and also the concern *resolution* process.

### What is the history of concern resolution?

The current rule for resolving concerns is somewhat ambiguous. We have generally treated a blocking concern as "inviolate" and not overridable by the team; but we have at times applied substantial pressure to members to resolve their concerns. The official rules from [RFC #1068](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md) which chartered the language design team declared our intention to use a consensus based process but also included [rules regarding cases where consensus could not be reached](https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md#lack-of-consensus). Those rules stated that the subteam leader was empowered to make the decision after consultation with the core team (now defunct). The lang team then later [documented a rule](https://lang-team.rust-lang.org/decision_process/reference.html) requiring a single sustaining vote to continue a concern, but we've not used that rule in practice, and that entire decision process has never been truly implemented.

Over time the author has observed that striving for full consensus creates perverse incentives, causing owners to prematurely "water down" their proposals to avoid generating controversy. It gives more to people who are more willing to upset others or risk discomfort.

### How did we arrive at this proposed concern resolution process?

The proposed process aims to *normalize* the idea of resolving a concern by making it mandatory to have a meeting once quorum is achieved. It also clarifies that the design owner is not required to make changes in response to a concern. They **are** required to give the concern author a fair chance to make their case. Similarly, the lang team is expected to hear that case and weigh it carefully.

On the flip side, concern authors are not required to say they agree when they do not or to water down their concerns. They **are** required to put in the time to fully explain their concern and, if the team does not agree, to abide by that decision.

### Why add the champion/design/impl metadata into the github project board?

The idea is to drive greater clarity about who is doing what work. This should in turn empower those people to drive decision making.

### What do you want from this meeting?

I would like to finalize the decision on adopting this process. It's always possible to make changes later if we feel it is not working.

---

# Discussion

## Attendance

- People: Josh, Nadri, David Wood, TC, Tyler, Santiago, Niko, Yosh, Taylor Cramer, eholk, Martin

## Meeting roles

- Minutes, driver: TC

## Vibe check

Adding the usual section here for a team vibe check.

### nikomatsakis

I like it! Surprise!

I'm disclined to cut any part of it at present.

### tmandry

I'm feeling optimistic about this proposal. I think we need to listen to the contributors who tell us our process hasn't been going well for them, and personally I'm at a point where I think the status quo is basically indefensible. In light of that, I think we should adopt the proposal.

*Notes from what tmandray said out loud:*

* I think it's really stressful for people to not know where they stand and what they have to do to resolve it.

### Josh

Big :+1: for 90% of this proposal. The concept of champions seems right, many of the processes make sense, and I like the natural tension between "design owner decides whether to accept feedback, team decides whether to accept design". That also creates a dynamic in which we as team members should largely be reviewing designs, and if we get into the space of *doing* designs we're putting on a different hat, either champion or design owner.

I also think this in some ways codifies the processes we've done *informally* in the past for successful RFCs, and extends it to all proposals/RFCs.

I do think that the process around concerns is largely separable, and not particularly inherent or tied to the concept of champions. I also think it has some issues that need addressing. That's especially true if this applies to one-way-door steps; it's less of an issue with two-way-door steps, except insofar as it creates pressure on the one-way door.

Rather than keeping the two tied together and not adopting it until everything reaches consensus, I would be in favor of separating the two, and adopting the remainder of the champions proposal largely as-is (modulo some of the tweaks suggested in this Q&A section), assuming it has consensus.

### TC

This sounds right to me. I like that this revised proposal is closer to our process today, so it's more of an incremental step and iteration on the previous "lang liaison" role.

There is a tradeoff for us to be aware of, I think, about how we spend our time between either becoming more involved in managing the design of particular features ourselves versus spending time to better empower others to do this better, e.g. by better documenting and externaling our values. But I think that for, the moment, focusing on better shepherding along features is probably right.

As noted below, I'm curious how it will work out having a lang-advisor as a champion, and I probably think that to make that work out well, the lang-advisor needs to commit to joining in on many if not most of our calls to get the kind of "feel" for us that we have for each other.

I'll note also that I think this proposal will work out well with revisions that we're making to the edition process for this year, in terms of the champion being the one responsible on the lang side for tracking and ensuring the readiness of an edition item, when the championed feature has edition relevance. In that sense, I see this champion proposal as probably an experiment for something that perhaps other teams might usefully later adopt.

### Nadri (not lang team)

I like it. This isn't far from today's processes but way clearer, and I like that it clearly empowers the design/impl owners to make decisions according to their best judgment, with a clear champion to help if they have questions.

As a lang advisor I also quite like that lang advisors can be champions because until now it felt like an honorary role and this gives it more meat. It feels closer to the old t-compiler member/t-compiler-contributor divide.

Also excited for anything that helps manage t-lang's load.

### Yosh (not lang team)

Vibe check on the vibe check: I'm really enjoying these vibe checks! Vibe check on the proposal: I haven't seen anything that was obviously wrong or concerning. This seems well-considered, and I'm a fan of iterating and refining our processes. I like it!

### Santiago (not lang team)

This sounds very good to me.

### davidtwco (not lang team)

I've discussed the proposal w/ Niko already and like it. Something like this would help improve clarity and make it obvious how to find out what next steps ought to be when you're advancing a proposal.

With my compiler team hat on, it's important that we establish the process for compiler agreeing to an experiment taking place - or at least having an opportunity to weigh in - and being involved in the tracking of the progress of that part of the process but that can happen after lang is happy with the broad thrust of this.

I'd also like it if in the implementation of this - we could work together (compiler + lang) to integrate these into a "how to contribute a feature" process for our parts of the project together rather than per-team processes, but that's not an immediate thing.

### eholk (not on lang team)

I like the proposal overall. I especially like the fact that it has a process for declaring that RFCs need a refresh. We have some RFCs that have been open for years that we clearly no longer believe in and it feels dishonest to keep these open.

On tracking things with project boards, I like the idea in theory, but in practice I've found project boards to be very high maintenance and tending towards Write-Only or worse, Write Once Read Never.

### Martin (not on the lang team)

Not in the lang team, but I'm very interested in hearing/following this process and hearing about the sources of friction in how the lang team operates.

## Niko's proposed agenda

* Discuss champions / staging first
* "Obvious next steps" that don't I think need suggestion
* clarify that champion is expected to attend meetings regularly enough, per TC's comment
* review with compiler team to discuss their role in approving experiments
* clarify that all issues on the project-board will also have labels
* clarify milestones:
* experiment is optional, not required
* rfc is required
* experiment plus rfc can go in parallel
* Discuss process around "Stale RFCs"
* Discuss concern resolution
* Meta: is consensus *required*? (NM feels no, in a lawyerly fashion)
* Summarize concerns
* TC's counterexample about naked-asm
* should we distinguish 1.5-way door (RFC) from 2-way door (stabilization) in terms of process?
* Interesting questions that can be discussed separately
* project board vs metadata-in-OP

## "Stale" RFCs

> * Features that have lain fallow for long enough require an RFC "refresh"

Josh: Speaking from experience, this can be really disheartening. I can definitely appreciate that designs can get stale as the language evolves. However, this seems like it has a default disposition of dropping things, rather than requiring someone to explicitly say "this design seems like it has gone stale due to XYZ, and needs an update before being implemented".

Getting things through the process can be a very heavy lift, and the idea of semi-automatically rolling this back feels really painful to inflict upon contributors.

I appreciate the problem is trying to solve, and I do think we need a solution for it. But as written this seems like it'll increase our workload *and* make life harder for contributors.

Nadri: we could rephrase this process to be lazy: if a feature has stayed untouched for a while, and someone is trying to resuscitate it, then t-lang may require a refresh.

Nadri: we can use the proposed processes: the design owner chooses whether to refresh, and the fact that the RFC is too old can be considered a valid concern to stabilization, to be resolved as usual

Josh: :+1: for the evaluated-on-demand version, in which we normalize the concept that stale things *may* need a refresh, and always ask ourselves the question. Also :+1: for Nadri's proposal for how to structure that.

---

NM: I do want to clarify that I don't want this to be an automatic mechanism. I want the automation to flag for us when something is hanging out there. It's more a mechanism for having the conversation.

Josh: Having as a default question we ask about whether something has gone stale (language has moved on and the design needs an update, or we now feel it's not the right solution to its problem), seems entirely reasonable and useful. And it sounds like that's exactly what Niko is proposing, so I think this is purely an issue of "update text of proposal to clarify intent" rather than any issue with the actual intended process.

NM: Reviewing for possible staleness is something we might do twice a year, maybe during goal planning. It's more of a retrospective.

tmandry: This is doing a service to RFC authors and implementors. It's reflecting reality, really. The lack of clarity around whether the lang team is aligned on something anymore is the problem that we're trying to solve so we can communicate the actual state of the world.

tmandry: I agree with Niko that this should occur on a less frequent basis. Not sure how to balance not wanting to spend a lot of bandwidth on deciding whether we are not aligned.

(Discussion about whether we need a team discussion to decide whether something is no longer wanted or whether just one of us looking at it might work.)

TC: One interesting recent example of that is `cfg(target(os = "..."))`, where we're being asked if we still want it. I look at it, and I'm not really sure whether others on the team might want it or not. It's exactly because we haven't talked about it in ages that I don't have a good read. So even for a simple one like that, sometimes we may just have to discuss it.

NM: To davidtwco, compiler team can use these labels as an opportunity to know whether to rip code out. I also think it's probably enough if somebody feels *strongly* aligned to go ahead and nominate for brief discussion and flag it, but per TC I see value in doing some regular review as a way to help build up team consensus.

tmandry: Agree that we can probably do this with a combination of opportunistic checking and some kind of regular review. We can figure out the details.

## Consensus required for changing consensus process?

NM: What do we need in terms of a consensus for changing the consensus process? From the formal rules, it seems like "no"; leads can decide how to deal with absence of consensus. I don't really see an obstacle to moving forward here.

TC: To queue up discussion here, let's state the diff concisely.

NM: What we're doing here is that, if you have a blocking concern, the burden of proof is on you to write up and justify why you don't like it, and that secondly, that once you've made your case, that you have to convince some subset of the team. Let's say that, for the moment, that this is one other person.

TC: This makes sense and I see this as writing down what the existing social expectation around our process already is today.

JT: The new process should be established with the old process. I don't think there has to be a way for things to move forward, if there's dispute about whether forward is the right direction. There's a difference between our process being lubricated by a social expectation and that being the process.

NM: My point was the old process is that leads make the call -- in practice that's taken the form of me twisting the arm of people behind the scenes from time to time.

tmandry: If we agree that this is the way that things are supposed to work, then we should write it down, as otherwise we're making this opaque for other people. I'm reminded of "the tyranny of structurelessness".

Josh: :+1: to writing down the process accurately, to be clear. We should write it down *accurately*.

### Caveat about concerns filed on behalf of all of us

NM: What were you saying about `naked_asm`?

TC: So we have a proposed stabilization -- it's a dual FCP with libs-api -- it's got a quorum of checkboxes (N-2). One of those is mine; I checked my box and immediately filed a set of concerns. With asm-related things, we're often at risk of underreviewing them and saying, "somebody must have checked this". In the context of having had issues with other recent stabilizations where we may have done that, and since I'm reviewing Reference PRs in this area, I decided to review it deeply.

Upon reviewing it, I find some things of varying degrees of concern, all of which should be addressed, from e.g. divergences from the RFC not mentioned in the stabilization report, to errors about the UB rules in the Reference, to interactions with features that happened after that RFC like `unsafe_attributes` and `#[target_feature(enable = "..")]`, etc. So it's not actually ready. But I'm filing these concerns, I believe, on behalf of all of us, and I don't really feel like in doing so I'm "buying" responsibility for this one.

Nor do I think it's the intent of the proposal here that I would be. So I raise this just as a delineating example for refining the wording a bit.

tmandry: I would expect all of these to be "insta-sustained" by various lang-team members, I don't think we need a design meeting to decide that it's not ready; there are outstanding concerns. If the person driving stabilization disagrees we could escalate.

tmandry: I do feel like we should have a QA subteam or *something* like that that checks some of these boxes.

Josh: Your point TC is valid. To frame Tyler's point in a manner of process, it just requires changing the default disposition of a concern is a design meeting to the default disposition *about which there is disagreement* is a design meeting.

NM: I think I should edit to say that this is a mechanism for resolving a disputed concern; I don't think we should ever "override" a concern without having had a thorough discussion first.

Josh: Valuable to say it is the *default*.

### should we distinguish 1.5-way door (RFC) from 1-way door (stabilization) in terms of process?

NM: I deliberately chose same process because I wanted RFC to be meaningful. I see the point but I also see it as setting us up for a trap where we override the concern in RFC but then we have to deal again at stabilization time.

JT: I feel like the pressure to stabilize can make it feeling like standing in front of a steamroller to deal with an issue that's nonetheless legitimate. As a concrete proposal, I think we should adopt a version of this as an experiment or trial run for 2-way or 1.5-way doors. See how it works, do a retrospective, then discuss how we feel for 1-way doors. It would give us experience with the extent to which this becomes a process hammer vs codifying what we want to do anyway. Best resolutions for contentious things have been when we are all on the same page saying we want to solve the problem but the question is 'how'. What concerns me is when we have dispute over whether we should actually be solving this problem or whether the cost of doing so spends too many innovation tokens for the wins that it gives us. The answer may not be "we should go forward, how are we going to solve this problem", we have to still be able to ask the question "should we do this" -- that's what gets resolved at the RFC level.

JT: It should be on the concern resolver to give falsifiable criteria to resolve the question, i.e., "how do we get an idea if this is too complex" etc. Having that 1.5 way door where concerns can get overridden, default is that it becomes an unresolved question that we revisit at stabilization. Question is, how do we not just retread? We don't do that if we'll just have the same conversation in 6 months. Very much on the concern author to say "here's what would make me wrong".

TC: Clarifying question, Josh -- concretely -- the process being proposed here is: I raise a contested concern, then we stop and I put forward my best argument, and I get to see if I've convinced anyone, and if I haven't, we go forward anyway. What you're saying is that you have concerns about that at stabilization time?

Josh: Yes. Stabilization is a 1-way door. We should not have a default bias towards "just ship it". If we can't get to a consensus, even a reluctant one, there may be a reason for that.

tmandry: I don't think this is a bias towards "ship it". If the process is, if any two people think we should not move forward, we don't. Maybe we just disagree on the facts.

TC: For me, consensus means something different from unanimity. If we're in a situation where I have concerns about something but four others on this team are telling me "no, this is OK", then I say to myself, "I don't see it, but I trust the fact that four other smart people think this is OK, so this should just move forward", and I consider that a consensus, even if my concern is still lingering, which is how I distinguish it from unanimity. I want to be clear, you're defending a requirement for unanimity among the lang team on stabilization?

Josh: I'm suggesting you need consensus with lack of objection. We've gone with a lot of things where most people are yes, some are "meh", that is fine. Not unanimity, but absolutely consensus. It seems different as team grows. If the team had 30 people then it's one thing. If you only have 5 or 6, and people have different areas of expertise, it makes sense that a concern may be represented by one.

TC: So if we have 4 +1's and a -0, you consider it consensus. If we have 4 +1's and a -1 you don't see that as a consensus?

Josh: For one-way doors, yes. That's our current process today: consensus without blocking objections.

NM: Being a good lang member requires understanding and reflecting a different point of view.

Josh: :+1: to that.

NM: To me, a process is just plain *incomplete* if it doesn't have a way to ultimately make a decision. I cannot understand a process that doesn't allow the vast majority of a team to reach a decision over a minority; it feels like it a lack of trust.

NM: Decision processes tend to have some fallback mechanism for this. E.g., at the end of the day, someone can be removed from a team, and so it can come down to "resolve your objection or be removed", but it doesn't feel like it should come to that.

Josh: Maybe we have consensus to start with this process at RFC time and not do it at stabilization time?

TC: No -- unless four people disagree with me here -- I'd like us to use the same process and standards at RFC time as at stabilization time, whatever it is, so that we paint a clear path from the RFC to stabilization.

(The meeting ended here.)

---

## Labels as the source of truth

TC: This is a nit, but while project boards are OK as a "view" into the data, I'd prefer that we keep the labels on the issues as the source of truth, adding whatever labels are necessary to that purpose.

TC: This aligns better with what we do for the edition process, it works better with my tooling, and it's easier to use GH search with it.

TC: Also, I just think project boards are always... kind of continuously fighting to avoid obsolescence and death.

Josh: :+1:, but I'm going to defer to whoever is doing the bulk of the tracking for what they see as the right mechanism here. That said, I like the idea of tracking experiments and accepted RFCs in the "same" place. Does it perhaps make sense to have a tracking issue for experiments?

NM: We do have a tracking issue for experiments. The project board is useful because it allows us to add metadata like champion etc; however, I think the invariant that "every issue on project board must have X labels; every issue with X labels should be on the project board" seems like it is best of both worlds.

Nadri: Would it make sense to assign (in github terms) the tracking issue to the champion at least? or track some of the metadata in the issue text.

tmandry: Project boards give a more expressive way to track things, e.g. each issue can only be in one state at a time, we have text fields, etc.

NM: Nadri, I tried that, but I found that it felt off. I felt like the design or impl owner was a better assignee; I also felt that the assignments were kind of harder to see when there are multiple people involved.

Nadri: OK, interesting.

## Expectations of lang-advisors as champions

TC: One of the most new and experimental parts of this proposal is, I think, expanding the champion role (what we might have called the liaison previously) to lang-advisors. I think this is probably OK but only with the caveat that the lang-advisor serving in this role talks with us enough to have a similar kind of "feel" for us that we have for each other. This probably means an expectation that the advisor join us on many if not most calls for the duration that the advisor is acting as a champion.

## Counterexample case study: naked_asm stabilization

TC: The proposal mostly sounds right to me, but to explore a case study that's a bit of a counterexample to the concern resolution process, I'd look at:

https://github.com/rust-lang/rust/pull/134213

Here, I'm blocking a quorum with concerns, but I don't particularly feel the need to take ownership of this one and schedule a design meeting and whatnot.

(Of course, maybe it will take a design meeting to work through some of them. But for most, they're really just a note for the author to fix problems.)

Josh: I think there's a meaningful difference between "a design meeting is a good default way to solve a concern that isn't getting resolved" versus "a design meeting is mandated". I'm hoping that this is intended as the former; having it as a useful default seems like the right answer, and we don't need to mandate it.

## Stabilization process

Santiago (not the main point of the discussion but ...):

- Should the stabilization process explain more the expected level of maturity or testing of the thing being stabilized?
- Should that also explain possible cross team discussions?
- Shouldn't it also have some kind of exahustive testing period, testing process or something?

## Quorum

nikomatsakis: I wrote this "currently: 2/3 of members have checked their boxes" but I think it is wrong. Anyway it's not the main point, I'm not trying to propose changes to rfcbot process per se.

## Are all "Feature milestones" intended to be required? In sequential order?

Josh:

- Is the intention that *every* feature go through a lang experiment *before* an RFC?
- Is the intention that *every* feature needs a preview phase, even if it's already gotten sufficient evaluation?

## Concern resolution: is this still tied to champions, does this still make sense in this proposal?

Josh:

> * If concern author is not satisfied, RFC author can poll the lang team. 1/3 of full team members, or 2 people, whichever is more, must support the concern or else we will move on. This number includes the person who originally raised the concern, if they are on the lang team proper.

First, a clarifying question: this section seems to talk about FCPs in general, but then this says "RFC author". Is this *exclusively* for RFCs (which are usually a two-way door until stabilized), or does this also apply to FCPs for stabilization? Most of what I've written below is most critical when dealing with one-way doors rather than two-way doors, modulo the usual pressure that happens when designs get momentum and then reach the one-way door at the end. The phrasing that

> Once the RFC is accepted, it is considered "bad form" to relitigate design decisions covered in the RFC unless new data or design alternatives are available.
b
would be an example of creating that pressure.

There was some discussion on this the previous time this proposal came up, that I thought had led to separating this from the champions proposal, and focusing on the champions mechanism itself and the process structure. In particular, this no longer seems fundamentally tied to champions.

Ongoing concern that this seems like it creates a strong "bias towards yes", which I don't think is a desirable property for language design.

(Also, as an observation, past approaches to this have used a threshold of one second for a concern, rather than a third of the team. Not endorsing that either, but observing that this proposal sets an *even higher* threshold than previously considered.)

That said, big :+1: to the mechanism of "a concern once we hit quorum automatically becomes a design meeting", and I think at the very least, we should frame this as "if there's no support for the concern in the design meeting, the concern author should be very very hesitant to maintain a blocking concern, and should strongly consider alternatives such as mitigations or moving the concerns to an unresolved question for re-evaluation at stabilization, rather than blocking the FCP."

NM: I decided to include it for a few reasons. One, I think it's tied together with the idea of "this is our overall process for keeping forward motion". i.e., champions are only a piece of this, the project board, feature milestones, design/impl owners, are also part of it. Second, I wanted to avoid more meetings.

Josh: For the latter, that only works to avoid more meetings if we're prepared to ship the whole thing as a unit. For the former, "keeping forward motion" is not an unalloyed good, it assumes that the correct direction for a proposal in its current state is "forward".

Josh: In the interests of having a concrete proposal to address this:

What if we try a version of this (modulo some iteration on the exact process details) *for two-way doors*, with some guardrails to make sure it doesn't create undue pressure on one-way doors?

## Stage between experimentation and RFC acceptance

davidtwco: It makes sense to increase the bar for accepting an RFC to have fewer unresolved questions on RFC acceptance - so these things aren't left for when stabilisation is being considered.

It would be nice to be able to indicate that an RFC has largely gained consensus - having the whole RFC unaccepted makes it feel like the whole design is still up for debate, even if it's resolving a single unresolved question that remains and the rest has consensus. It wouldn't need to be a formal stage necessarily, just a indicator of some sort.