owned this note
owned this note
Published
Linked with GitHub
# lang team procedure proposal
## Goals
* We wish to establish that *lang team work happens primarily in project groups*
* We wish to offer support for folks writing RFCs
* We wish to ensure that RFCs better reflect project priorities
* We wish to eliminate "RFC limbo", where an RFC is opened but it's not clear what its fate is
## Overview
```mermaid
graph TD
HaveGoodIdea[Have a good idea]
FileLangProposal[File proposal issue<br>on lang-team repository]
RejectWithExplanation[Proposal closed,<br>with an explanation of why]
OpenPR[Open a rust-lang/rust PR<br>implementing the idea]
PRIsApproved[PR is approved<br>by the lang team]
MergePR[PR is merged<br>by compiler team]
ApprovedIssue[Add issue to backlog<br>with liaison labels]
CharterProjectGroup[Charter a project group]
IterativelyDevelopRFCs["Iteratively develop RFC(s)"]
HaveGoodIdea-- Idea seems ready -->FileLangProposal
HaveGoodIdea-- iterate on internals/zulip/etc -->HaveGoodIdea
LangTeamSolicitsProposals[Language team list of<br>proposals we'd like to see] -- An intrepid volunteer! --> FileLangProposal
FileLangProposal-- Concept declined by lang team -->RejectWithExplanation
FileLangProposal-- Idea is simple<br>and approved -->OpenPR
OpenPR-- Lang team review -->PRIsApproved
PRIsApproved-- Compiler Team review -->MergePR
FileLangProposal-- Idea is complex but approved<br>and lang team liaisons volunteer -->ApprovedIssue
ApprovedIssue-- Lang team liaison has time now -->CharterProjectGroup
ApprovedIssue-- Lang team liaisons are <br>busy with other things -->ApprovedIssue
CharterProjectGroup --> IterativelyDevelopRFCs
IterativelyDevelopRFCs -- present to lang team --> IterativelyDevelopRFCs
IterativelyDevelopRFCs -- RFC accepted --> OpenPRWithGroup[Open a rust-lang/rust PR<br>Project group supports implementers<br>Project group reviews and tests PRs]
```
## Implementation, questions and notes
### Chartering a project group
We've historically used RFCs for this. This is because it represents an important choice: we're committing to the "intent to solve a problem" and sometimes to the "general shape" of the solution (but not the details). On the other hand, our experiences using RFCs for this so far hasn't felt *that* great. Plus, there are definitely going to be projects that are relatively simple, and maybe an RFC feels overkill.
If we do continue to use RFCs, we should develop some templates and guidelines:
* Keep them short and move them through quickly if there isn't much controversy or discussion needed.
* For more controversial options, use the RFC to explore the problem space, document use cases and motivations, and gather concerns.
An alternative to RFCs would be to use a PR against lang-team repo with an rfcbot fcp, or even permit consensus within meeting.
### Managing proposals and visualizing the backlog
At the start of each triage meeting we will review the "proposal board", which is a github project with the following three columns:
* Incoming -- newly filed proposals
* Active -- shows the queue for each member
* Backlog -- shows some number of ideas we've approved but don't have time to do now
We'll label each issue with labels for the liaisons. Each item in the "active" or "backlog" columns must have at least one team member label, which indicates the liaison(s) or prospective liaison(s).
Issues in the "active" column will also have labels indicating their status at a glance.
The backlog column shows items approved by the language team, for which one or more members are willing to serve as liaison, but none of them have the bandwidth for right now. The backlog should stay in roughly sorted order, such that if a team member has bandwidth they're likely to take the highest-ranking item that has their label on it. This gives a public view of what we're working on and when we're likely to get to things, as well as steering people towards things they could help with if they want to free up some bandwidth.
Example: https://github.com/rust-lang/lang-team/projects/2
We will also have a list of ideas for which we would like to solicit proposals. We can maintain that list directly in the lang-team repository `README.md`.
### What about creating PRs?
In some cases, people today create PRs that implement an idea. If this happens, just as with a PR that requires compiler team MCP, we can decide if the idea seems too big to enact without an RFC. If it feels like it can be a PR, then we just proceed as normal. If we feel an RFC is required, then we either close the PR mark the PR as blocked (it may be useful to keep it open for experimentation purposes) and encourage folks to create a proposal.
### What about when people don't follow this process?
There are various ways that people can fail to follow this process:
* They can open an issue for "early stage" feature requests
* Outcome: redirect that conversation to internals, or encourage the creation of a proposal (close the issue)
* They can create a PR that implements the change
* Outcome: if the idea seems PR scale, we can run with it, but otherwise encourage creation of a proposal and close the PR (or mark as blocked)
* They can directly open an RFC without any lang team liaison
* Outcome: close the RFC and encourage creation of a proposal
### What happens to existing RFCs?
Lang team will go over them and decide if we can "retrofit" them into this process by assigning a liaison. If not, they will be closed and people encouraged to create a proposal.