The 2017 revision to the RFC process (diff) simplified things enormously. The barrier to entry is now low, with literally the only requirement being to create a task, and there's no unnecessary formalities required on the author's part.
But, I also believe this change hasn't helped RFC authors and stakeholders to be able to anticipate what will happen between now and approval.
Objective and scope
Take what we've learned in the past three years, and add a bit of structure back to our process.
- It should be naturally be clear what the stakeholders likely want to know about an RFC, who these stakeholders are for a given RFC, and at what point they need to know the things they want to know. (For example, it is not needed to have a solid plan and proof of concept at filing of the RFC.)
- RFC authors should gain greater autonomy, and receive a quicker overall process by knowing what is happeniing now and what will happen next, without them needing to ask or be told by someone.
This is meant to be a retrospective and inform an interative change to our process. To constrain ourselves:
- No new requirements for what's needed at intial RFC task creation.
- No add new process overhead for RFC authors to follow.
Initial thinking points
- What are are questions that participants (esp. TechCom members) ask on almost every RFC? These are good things to consider adding into a boilerplate, FAQ, or other self-discoverable process.
- What are the steps that participants expect to be followed on most RFCs (e.g. define and consult stakeholders before scheduling meetings). We should make it hard to mistakenly think that a step has already happened. Also try to make internal triage work easier to rotate and transfer for TechCom internally.
- What steps have we forgotten during past RFCs? What steps should have happened earlier or in a different order? We can amend the process in a small ways to optimise against such inefficiencies.