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.
Many thanks for proposing this Sophie. I’ve had a quick read through the text and it all seems very sensible. I was waiting to reply so I had time to digest it a bit, but nothing new has come from that, so I think the best thing to do is adopt the process and start using it.
I converted the RFC into an MR such that we are now resembling the planned RFC workflow. This also reminded me again, that editing on Discourse is highly restricted. Hence, my links in the original post are useless now. The MR is here
I added some clarifications, the discussions are now limited to Discourse, list of concerns is still on GitLab, since we can’t edit Discourse posts.
Since there haven’t been a lot of discussions, I would suggest that we are slowly moving towards final comment period. If there haven’t been any concerns raised on Friday, I would announce a final comments period via a blog post, TWIG, and an announcement post on Discourse if that’s possible.
In general, I think it might be best if we just start using the RFC process and then implement the lessons learned later.
Personally, I would have preferred it if the proposal for just designing and writing glycin went through an RFC process. Contacting the involved people one by one is cumbersome, there is no decision written down anywhere, and I would prefer to know that everyone involved had a proper place to comment.
Sure, that’s a choice that you can make if you think it helps you.
I would never want to do that because it only leads to bikeshedding, burnout, and lots of stop energy when uninvolved people inject themselves into the process.
It might be nice to define what gives the RFC repository legitimacy, such as links from the handbook, gnome.org, CoC.
I would prefer this to be less Gitlab-centric (much like Sébastien mentioned above). I understand that de facto Gitlab will be the place, but I’d rather refer only to the repository. I can make wording suggestions on the MR if you want.
Should we immediately define a way on how RFCs can be replaced by new RFCs?
I am not sure if requesting to amend commits for each change is good for an RFC, seeing the individual changes and only squashing everything before accepting the RFC seems more transparent.
I don’t think it has anything to do with gnome.org or the CoC, but it should be added here wenn accepted Governance
I am not entirely sure what you mean. Do you mean the mentioning of GitLab specifically in the RFC? I tried to generalize it to “currently used git forge” in an older version, but I dropped the flexibility in favor of being much more understandable. Note that the RFC allows limited changes to existing RFCs, so it would be no problem to change it when we move to Forgejo in 10 years. Also, there is a README file that explains the process in simple terms, that can be changed without an additional RFC. But also, having RFCs that superseed RFC-0001 are not really an issue.
I think RFCs can just state that they do. I intentionally did not enforce complex form requirements for RFCs in general to keep the process simple and flexible.
I’m not sure what you are referring to. The RFC proposal explicitly forbids changing the history after the initial renaming:
However, after amending the original commit of the RFC to specify the RFC's number, the branch must not be rebased, nor should its commits be squashed.
Yes, I mostly meant the usage of the term “GitLab”. I think it can mostly be avoided. Another thing is this:
The number is determined by the monotonically increasing MR number assigned by GitLab
Monotonic MR numbers are Gitlab-specific, neither Github, nor Forgejo, nor Gitea do that. They also call them pull requests though, so maybe it doesn’t really matter.
I was not thinking of complex rules, just a single sentence that RFC can be replaced or obsoleted by newer RFCs.
Ah, that did d not read clearly enough to me. The intial instruction of amending had me thinking that changes should always be amended, just not rebased or squashed upon merge.
What I have failed to mention in both of my previous comments, I think overall the RFC proposal is in a very good shape and something the project could greatly benefit from, great job!
I am announcing the start of the final comment period for the adoption of this RFC. We are deviating from the proposal’s 14-day period for this occasion and instead will consider concerns raised up until October 4th at 23:59 UTC.
In that case, the person proposing the change cannot insist on the proposed changes, raise a concern, or open a competing RFC to be discussed as an alternative.
I can’t parse that.
I cannot insist on the proposed change, and I cannot raise a concern, and I cannot open a competing RFC to be discussed as an alternative?
or,
I cannot insist on the proposed change, I can raise a concern, and I can open a competing RFC to be discussed as an alternative?
My big issue with this RFC process here is that is focused on teams. There are stakeholders mentioned, and that members can be stakeholder, but the proposer does not need to declare members stakeholders, and there is no mechanism for them to become stakeholders in any other way.
My immediate problem with this is that if someone creates e.g. an RFC for an AI policy and just makes teams stakeholders, then most GNOME members opinion does not matter for the outcome. This is extremely anti-democratic.
From a more general perspective, this creates a huge incentive to be in a team, and specifically to be the voice of a team. It will encroach the current dynamics even more than already is the case. Gatekeeping will be a thing. The problem with GNOME becoming older will become even more the case, and getting new people on board will become harder. The people who have the privilege of getting payed full time already are favored once again.
It creates a system where not all GNOME members are the same and not all of our opinions have the same weight.
