Change Details

### Preamble 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. (NOTE) Current version: **<https://www.mediawiki.org/wiki/Requests_for_comment/Process>.** ### Objective and scope 1. 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**. 2. 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. Scope: * 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. ### Problem statements 1. There are questions that participants (esp. TechCom members) ask on almost every RFC. This shouldn't be the case. 2. There are certain sub process that participants expect from most RFCs. We should make it hard to forget about these. 3. 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. ### Proposal 1 * ...

(NOTE) Current version: **<https://www.mediawiki.org/wiki/Requests_for_comment/Process>.** ### Preamble The 2017 revision to the RFC process ([diff](https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Process&type=revision&diff=2653022&oldid=2577586&diffmode=visual)) 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. ### Proposal 1 * ...

### Preamble 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. (NOTE) Current version: **<https://www.mediawiki.org/wiki/Requests_for_comment/Process>.** ### Objective and scope 1. 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").Preamble 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,The 2017 revision to the RFC process ([diff](https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Process&type=revision&diff=2653022&oldid=2577586&diffmode=visual)) simplified things enormously. or by the author analysing past RFCs.The barrier to entry is now low, This will give authors more **autonomy**with literally the only requirement being to create a task, and should allow for the process to be **quicker overall**there's no unnecessary formalities required on the author's part. 2.But, Document what sub-processes we believe are needed for most RFCs before we allow ourselves to believe a proposed solution can be considered approvableI also believe this change hasn't helped RFC authors and stakeholders to be able to **anticipate what will happen between now and approval**. 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.### Objective and scope Scope:Take what we've learned in the past three years, and add a bit of structure back to our process. * Not a complete overhaul. * No new requirements for RFC authors.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.) * We'll add "should" and "recommended" statements that RFC authors may follow. * We may add new requirements for TechCom members to followRFC 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. ### Problem statementsThis is meant to be a retrospective and inform an interative change to our process. To constrain ourselves: 1. There are questions that participants (esp. TechCom members) ask on almost every RFC. This shouldn't be the case. 2. There are certain sub process that participants expect from most RFCs. We should make it hard to forget about these* No new requirements for what's needed at intial RFC task creation. 3* 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. There may be midefine and consult stakes we've madeeholders before scheduling meetings). If we can amend the process in a small way to prevent these,We should make it hard to mistakenly think that a step has already happened. we should consider doing soAlso try to make internal triage work easier to rotate and transfer for TechCom internally. 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?).* What steps have we forgotten during past RFCs? But for the common case, we can probably come up with a default format to recommendWhat steps should have happened earlier or in a different order? We can amend the process in a small ways to optimise against such inefficiencies. ### Proposal 1 * ...