The 2017 revision to the RFC process simplified things enormously. I believe this has been good for the start of an RFC. The barrier to entry is low, and there's no unnecessary formalities or bureaucracy.
But, I also believe it's made it harder for RFC authors and stakeholders to anticipate what's going to happen when and how.
Let's take what we've learned since 2017, about processing RFCs, and incorporate it into the process.
Objective and scope
- Document what aspects an RFC should have in order to be considered ready for wider discussion (e.g. moved from being a draft in "Backlog", to "Under discussion").
Documenting these aspects will enable authors to get further into the process without being blocked on "discovering" these aspects, e.g. through helpful participants asking the questions, by TechCom, or by the author analysing past RFCs. This will give authors more autonomy, and should allow for the process to be quicker overall.
- Document what sub-processes we believe are needed for most RFCs before we allow ourselves to believe a proposed solution can be considered approvable.
The purpose of point 2 is to allow RFC authors and stakeholders to better anticipate what will happen. I believe that currently, it is generally unclear to participants whether an RFC could be put on last call if TechCom reaches consensus, or whether they plan to involve others or ask certain questions still before proceeding to that step.
- Not a complete overhaul.
- No new requirements for RFC authors.
- We'll add "should" and "recommended" statements that RFC authors may follow.
- We may add new requirements for TechCom members to follow.
- There are questions that participants (esp. TechCom members) ask on almost every RFC. This shouldn't be the case.
- There are certain sub process that participants expect from most RFCs. We should make it hard to forget about these.
- There may be mistakes we've made. If we can amend the process in a small way to prevent these, we should consider doing so.
We should pick of few of these and document them as recommendations. I also think we should keep the process flexible so that it can scale to all sorts of small and big ideas, and thus no mandatory fields (I think?). But for the common case, we can probably come up with a default format to recommend.