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. 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).
  • 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.
• 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).
  • 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 accepted, 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 is 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 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. 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 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.