The proposal looks promising. I have two general comments.
RFC-0001 is quite GitLab-centric. In the future the detailed instructions would need to change more often (in case of changes to how GitLab works, or in case we move to another solution). So maybe the RFC could have an “implementation” section with the detailed procedure to follow; and in the other sections, have a description in more general terms (something more unlikely to be modified later on).
This is not only for RFC-0001, but maybe a good practice for future RFCs as well, to separate out a section that is more likely to change in the future.
My other comment is about the timing and evolution of an RFC. I see three scenarios:
- Writing an RFC as an intent to work on something, but the work has not yet begun.
- Writing an RFC when the work is half-done, a prototype is available for wider testing and comments before the finish line.
- Writing an RFC when the work is mostly done, perhaps then turning the RFC into a GNOME-wide Initiative to port the projects (what we currently have; formerly known as the GNOME Goals).
Would it make sense to distinguish RFCs depending on how complete is the implementation? With some sections written explicitly in a way that is easy to be changed if the need arises, especially for early RFCs.