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 “Roadmap” part of the proposal.
Lack of clear rallying points. One thing that made the run-up to the 1.0 release so exhilarating was the way the release focused our effort: there was a big overarching goal we were all working toward, which led to a number of fairly clear-cut subgoals that everyone could pitch in on.
Since then, though, we’ve never had quite as clear of a “north star”. We’ve communicated some very high-level plans, and had success rallying efforts around self-contained projects like MIR. But we don’t have a systematic way of rallying our efforts around important goals on a regular basis. This gap is a shame, because there are many people eager to contribute, who we should be directing toward common, important goals with good mentoring opportunities. Likewise, there are lots of people who could provide useful perspective on goals, or even provide leadership on initiatives, who don’t have an outlet today.
Relatedly, it can be difficult to contribute at the RFC level. Is the problem you want to solve a priority for the relevant team or wider community? When it comes to the core language, there is only so much design work that can be in flight at once (since it all needs to fit together), so greater clarity on priorities and motivations is essential.
Idea: publish a roadmap on a regular cadence, e.g. every two release cycles (12 weeks).
The roadmap would contain, at a minimum, a small set of “major initiatives” for that period. An initiative might cover any phase of development, e.g.:
- Early investigation: For example, building out NDK support in rustup or exploring implications of various memory model choices.
Design: For example, working out a revised design for
randor const generics.
- Implementation: For example, the MIR initiative or rustbuild.
- Documentation: For example, focused effort on updating API docs in a portion of the standard library.
- Community: For example, launching RustBridge.
And potentially many other categories as well.
Initiatives are intended to be a primary rallying point for the community, and thus should share some basic traits:
- Clear scope: an initiative should have clear-cut goals that can actually be finished. So, an open-ended goal like “MIR” doesn’t fly, but “Get MIR-trans working on all of crates.io” does.
- Timeboxed: relatedly, an initiative should realistically last at most, say, 24 weeks (two roadmaps).
- Commitment: There should be some level of commitment from multiple people to actually work on the initiative. In particular, the initiative should list some primary points of contact, and ideally mentors.
Each initiative would have a dedicated status page with this information, links to issues or other materials, and potentially a FAQ. We’ve often found that there are recurring questions (“When is MIR going to be turned on by default?”) about big, ongoing work. The roadmap and status pages give us a highly visible, central and curated place to put this information.
The roadmap should be set via an open consensus process in which anyone can propose or influence initiatives. The initiatives should fit criteria like those listed above, and should also fit into an overall vision for Rust’s evolution over a longer period.
Details to be worked out:
- Can initiatives be added mid-stream?
- Full guidelines for initiatives; how many should be in flight at once? Needs to be a small number to make this practical and useful (it’s a form of curation/rallying).
- What is the process for deciding on the initiatives?
- Do we divvy things up by subteam? That would make the discussion easier, but doesn’t allow for cross-cutting initiatives very easily.
- Can we find less boring terms than “Roadmap” and “Initiative”?
- Can we also include the “feature pipeline” and other long-running concerns into a roadmap somehow?