I've recently written a blog post enumerating several ideas for improving Rust's RFC process. The post contains three separate (but interdependent) proposal sketches, which I'm eager for feedback and discussion on. I'm carving out each proposal as a standalone thread here on internals.
At the heart of Rust's open development is the RFC process. Every major
change to the language, compiler, core libraries, tooling, and policy go through
an RFC writeup and consensus-building process. The process served us incredibly
well in clarifying our technical direction on the road to 1.0, and has continued
to be highly active since then, with on average about 2 RFCs merged every week.
But it's not all roses. There's been a growing sense among both Rust leadership
and the broader community that the RFC process needs some further refinement as
we continue to grow the community. I want to lay out my view of the problems and
sketch some possible solutions, based on extensive discussion and brainstorming
with many others on the team.
Each idea operates at a different scale (from big-picture to low-level
mechanics), but they are intended to fit together into a whole; each one
supports the others. Ultimately, these should result in a single RFC, but in the
meantime I'll start a discuss thread for each proposal.
There is a clear common theme to all of the problems I want to raise:
communication. We need to find ways to better scale up lines of
communication around the RFC process, and for Rust core development in general.
There is also a cross-cutting concern: a need to increase our focus
on mentoring and the path to team membership. @wycats has a great saying
about measuring the health of the team structure:
Being a very active contributor who is not yet on a subteam should feel very
close to actually being on that subteam.
Shooting for such a state of affairs has many benefits, not least of which
is increasing the scalability of our community.
This thread is for the "Async decisions" part of the proposal.
Proposal: Async decisions
There is room for improvement around the way that the subteams themselves
work. Today, subteams reach decisions on RFCs and other issues in (bi)weekly
meetings. There are at least two problems with doing so. First, since the
meetings have a limited duration, **we often run out of time without finishing
the active business, introducing delays**; similarly, because of the high amount
of RFC activity, **the subteams often operate in "reactive" mode, more than
Another issue is that meetings provide, in some sense, the "wrong defaults" for
making decisions. We have to be careful to ensure that all the rationale for a
decision is present in the online discussion thread, and that any new rationale
that came up during a meeting means that the decision is delayed, to give the
full community a chance to respond. The point is that, **while we work hard to
provide this transparency, it requires that extra work**. At the same time,
there is often good discussion in meetings wherein the subteam members build up
a set of shared values -- thereby missing the opportunity to argue for those
values to the wider community. Finding a way to move decision-making to a more
public, asynchronous system seems ideal, though meetings do have the benefit
of providing a steady cadence to ensure that business is getting done.
Idea: move away from video meetings for decision-making, instead reaching
decisions entirely in the associated comment threads.
By moving the decision-making process fully online, we make it transparent by
default. That is not to say that subteam members -- or anyone else -- will never
have private conversation, of course. Just that this particular bit of business
is better conducted online.
The key to making this work is automation. Right now, the meetings provide a
convenient "forcing function" to ensure that decisions are being reached in a
somewhat timely fashion. To ensure that we still make steady progress, we need a
dashboard for every subteam member, showing them precisely what outstanding
items they need to weigh in on -- and that list needs to be kept manageably
We'll need a dashboard tool that can pick up on special text from subteam
- Calling an RFC/issue into FCP
- Approving/disapproving FCP
- "process: fcp r+"
- "process: fcp r-"
- Extending FCP
- "process: fcp extend" (for one more week by default; possibly give parameter?)
- Approving stabilization/RFC merging
- "process: r+" (ideally followed up by some commentary)
- Weakly objecting
- Just leave a comment, followed by a "process: r+" once you are satisfied
that the objection is addressed or that it's OK not to address it.
- Strongly objecting (i.e. blocking acceptance)
- "process: r-" (followed up with objection)
- Abstaining (possibly?)
The dashboard tool would track the current status of RFCs/issues facing a
decision, and would track the various timelines involved, e.g. that RFC FCP
lasts for one week.
We can and should continue to hold video subteam meetings (they're high
bandwidth!), but for more forward-looking purposes: discussing specific
early-stage RFCs, brainstorming, and prioritization. We can explore recording
these meetings, and potentially opening them up to additional stakeholders who
are not part of the subteam.
Details to be worked out:
- A plausible story for automation that retains the consensus process and is
likely to keep things moving.
- Can the automation itself be responsible for moving to FCP/merging? Or at
least provide a pushbutton way for doing so?