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 actively leading.
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 short.
We’ll need a dashboard tool that can pick up on special text from subteam members for:
- Calling an RFC/issue into FCP
- “process: 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?)
- “process: ack”
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?