I’ve been thinking a lot about RFC and stabilization reform. This has been partly inspired by my own experience and partly by insights from reading Rust2019 posts.
(EDIT: reformatted to make it less of a wall of text)
(EDIT: summary comment)
This post is intended as more brain-fodder. I had previously posted this pre-RFC which was an (admittedly extreme) proposal for attempting to fix some problems I and others have observed with current processes.
This post takes a more open-ended approach by listing some problems and potential solutions I came up with, smaller and more orthogonal steps. Also, I have intentionally avoided the question of where discussions should be held and what their format should be. I think that’s worthy of its own thread.
In order to scale processes, more needs to be automated.
rfcbot Table of Comments.
See (the pre-RFC). The idea was that rfcbot can be used to help maintain a structured, always-up-to-date summary of discussion. This can help reduce re-posting of the same idea, while also allowing people with new ideas to jump into discssions without having to read long threads.
Automate the unstable book.
The unstable features book was intended to be a way to keep track of what features are in the works. However, many of its pages are just obsolete, and in my experience, one just needs to go read the tracking issue anyway. I propose doing away with the unstable book and instead having rfcbot or some other bot keep track of every features status with a link to the tracking issue. This would be presented in the form of some webpage/dashboard with a big table. More below.
Automate unresolved questions and the creation of tracking issues, etc.
When an RFC is merged, some human (often @Centril ) creates a tracking
issue and adds a checklist to the OP with unresolved questions and other
TODOs before stabilization. I propose that rfcbot should be used to do
this instead. During the RFC discussion and FCP, team members can add an
unresolved question (e.g.
@rfcbot question Should the foo have a quux bar?). When the FCP merge is complete, rfcbot automatically merges the
RFC, creates a tracking issue, and adds unresolved questions to the OP.
Throughout the rest of the process, rfcbot can be informed via other
commands when work items are completed.
Unified tracking from proposal to stabilization for features
If rfcbot is used for more process stuff, it has more semantic info about the process, which means it can expose all of this information in some sort of web dashboard. In my mind, I envision a big table including all RFCs under discussion, all RFCs in various stages of FCP, all RFCs that have been canceled or postponed, all unstable features in the compiler, libstd, and other tools, all stabilization FCP proposals, etc. Moreover, this dashboard would be searchable. It would be everyone’s one-stop shopping to see what is in-progress and how far it has gotten.
I already mentioned this, but I think it is important to expose closed and postponed discussions. This makes it easier to research for new proposals and documents paths that we have chosen not to take.
Experimentation without any guarantee of stabilization
I observe that there
is a tension between wanting to play with a feature and try it out on
nightly Rust but not being sure if we should ever stabilize it. The
feature is an interesting
example. Two language team members simply do not feel that Rust should have
this feature at all, but other team members would like to see it stabilized.
Currently, in my experience, the acceptance of an RFC seems to be more or less
a guarantee that some form of the feature will be eventually stabilized. The
eRFC process is intended as a way to experiment with changes and require an
actual RFC before stabilizing. I would like to see this formalized and
I propose that we add a research and development (RnD) mode to rustc
-Z RnD). It is only available on nightly, and it enables RnD
features. An entire RFC is required to make an
eRFC feature into an
unstable one. It must then go through the normal stabilization process.
Notably, I think we should have a pretty low bar for adding RnD features:
the feature must not regress stable or nightly compilers and must have
support from a simple majority of the appropriate team.
Finish what is started… but don’t stress/oversubscribe team members
In the above-linked pre-RFC, I suggested bottlenecking the RFC process on a rust team member. The intent was to make sure we always have bandwidth to keep making progress on accepted proposals. However, I realized that this could also cause stress for team members.
While reading Niko’s Rust2019 post, it occured to me that we can use Working Groups to solve this problem: two or three persons from the appropriate WG would need to volunteer to shepherd an RFC to stabilization for it to be merged. This ensures the necessary bandwidth without placing a burden on any one person’s shoulders.
More holistic and objective evaluation.
While I realize that no such thing exists in most cases, I suggest that we can do better here.
We need some community-agreed set of design values by which we can holistically evaluate proposals and priorities. By necessity, I think this means we will need to de-prioritize or rule out some possibilities, as disappointing as that might be. I think we should be focusing on doing some things well, rather than everything OK.
These values, goals, etc. should be explicitly set out in a document somewhere and used as the ruler by which we measure all proposals.
We should continually re-evaluate the goals/values and our progress towards them to make sure they are still relevant.
One obvious candidate is for this to be a subsection in the annual roadmap.
Reducing noise and keeping discussions manageable.
I don’t really have much to add here beyond what I said in the aforementioned pre-RFC, but I think this is a real problem, I wanted it to be in this list.