Meta: Define initial goals/process for the RFC proposal system

[nerrad]

I've broken this issue out of my comment in 14812 and discussion in this issue is probably something that could eventually spill over to the WordPress project as a whole (but at a minimum could probably be experimented/iterated on in the GB plugin for starters).

I think for the purpose of clarity in communication and having people on the same page regarding the flow of things in using RFCs, it'd be good to at least start with some common understood stages that an RFC goes through.

Here's some copy/paste from my original comment:

On a meta level, being that this is the first official RFC, I think it's important to clarify what an RFC means in the WordPress project. To some it's an authoritative declaration of something that will be implemented, to others its simply a document describing a problem and the proposed solution to experiment with.

I would suggest that at a minimum, we take the time to define a simple process for RFC's (that we can iterate on). Eg.

A. Stage One: Proposal

• Proposal is given a name along the lines of this: RFC-Initial-{Issue/Pull Number}
• receive comments
• highlight potential problematic areas
• identify first iteration steps and what needs exploration/experimentation.

(this would be the stage this issue is at)

B. Stage Two: Iteration

Done in plugin.

• implement initial code experimentation based on Stage One.
• ongoing evaluation of problematic area, iterate to improve.

C. Stage Three: Final Draft for merge

• RFC is given the name RFC-Draft-{Issue/Pull Number}
• proposal updated for proposed merge to WP core.
• feedback period (defined period).
• decision.

D. Stage Four: Adoption

• give the proposal a number which could be the trac ticket number for merge to core. So for instance if the trac number was 14516, the proposal would be labelled RFC-Final-14516
• merge to core, scheduling, documentation etc.

[youknowriad]

Resharing my reply here :).

I think it's important to keep what worked well in the Gutenberg process and not alter it because of the introduction of the RFCs. The RFCs are here to solve a very specific topic which is the difficulty to state clearly props/cons/requirements of big technical problems in issues and slack and serve as documentation after the fact.

Merging an RFC doesn't really mean that this is the final call. It means that it's a decent stage to start iterating. The best way to make decisions is to experiment in the plugin and iterate (and this has been proved already).

So to answer your question, as you framed it. An RFC is "a document describing a problem and the proposed solution to experiment with." Once the experimentation is done and the code merged in Core, it becomes the defacto documentation of the problem and the solution.

[nerrad]

To be clear, I'm not suggesting RFC's be used for every new thing in GB/Wordpress. I only think (and agree with you) they should be used for new features/refactors that impact significant areas of WordPress core (as the widget refactor does). My suggestions are for a process to follow when we use RFC's. The problem as I see it (and as stated in my comments) is that we're adopting a mechanism for shepherding these huge technical problems but the process itself is still vague and prone to misunderstanding because of the different ways RFC's are used in projects outside of GB and WP.

[youknowriad]

Well I'm hoping my previous comment helps clarify the misunderstanding :) as I don't want to change the process of iterations and decision making in Gutenberg at the moment.

[nerrad]

Okay, then I'll close this simply because it doesn't appear at the moment it will go anywhere and I don't want to clutter up the triage :)

[youknowriad]

To be clear, I'm not against formalizing the process more, I think actually it's a good idea to have a docs/rfc/index.md clarifying the process: what should go to an RFC and what's the process. So there's value in this issue I think.

What I'm saying is that an approved/merged RFC is not considered set in stone, it's an approval to start experimenting and the experimentation can lead to changes to the RFC and once the code is merged in Core it becomes docs. If these are two statuses are named differently, I'm fine with it.

[youknowriad]

I'm grateful of the thinking about the triage team though :P

[youknowriad]

I'm reopening to actually add this doc.

[nerrad]

What I'm saying is that an approved/merged RFC is not considered set in stone, it's an approval to start experimenting and the experimentation can lead to changes to the RFC and once the code is merged in Core it becomes docs. If these are two statuses are named differently, I'm fine with it.

Right, to me that describes a process that you have in your head that is not explicitly described anywhere in the project. If we have people trying to guess that, or you continually have to clarify, that sounds like something that needs to be documented - hence the creation of this issue.

My goal here is not to make things overly complicated but instead to promote clearer communication in the project. I just think it's important if we introduce a new system/process there should be some documentation in the project (I'm aware of the post you did but that's not easily discoverable for people just coming to the RFC or into the project in the future.)

My suggestions were just intended as an example of something that could be documented (how I'd imagine it would work well).

For the documentation you add, I suggest it's linked to in any pull introducing an RFC.

[nerrad]

What I'm saying is that an approved/merged RFC is not considered set in stone, it's an approval to start experimenting and the experimentation can lead to changes to the RFC and once the code is merged in Core it becomes docs

I can't speak for others, but this to me is slightly different than what you articulated in the make.wordpress.org post where you said:

Accepted RFCs means the proposed feature is approved for implementation. Once implemented, the RFC becomes the de-facto documentation for it.

In the post it comes across to me very much that once the RFC pull is merged it is in its final form that will be implemented. Whereas what you're saying here suggests that the RFC itself might be iterated on.

I hope you understand I personally have no conflict with what is being done, I'm merely trying to pre-emptively guard against conflict that might happen because people read things differently.

[youknowriad]

Sure I can see how this can be misunderstood and thanks for raising the flag. Let's add this doc and share it to clarify.

In the post it comes across to me very much that once the RFC pull is merged it is in its final form that will be implemented. Whereas what you're saying here suggests that the RFC itself might be iterated on.

Obviously for me, "implemented" doesn't mean "final" but I understand that it can be read like that.

[aduth]

It's my understanding this is no longer needed since the RFC experiment was decided to have been ended.

Reference: https://make.wordpress.org/core/2019/11/21/core-editor-summary-for-november-20/