About a year ago, Emmanuele posted RFC: Governance here. While some parts of his proposal are already taking shape, there hasn’t been any public progress on a Request for Comments (RFC) process for the GNOME project.
I am proposing an RFC framework which will also help us build future governance structures transparently and by consensus.
First of all, I am glad to see that this is going forward.
To (virtually) benchmark this, what would be examples of changes that would go through RFCs? Either past changes that lacked such process, or future changes that are currently blocked and that could go through an RFC process?
Unless I missed something, we need to start a list of teams, while a few of them are well established (design, release?), the scope/existence of several of them is less clear to me, especially for core apps or circle apps (?).
I’m very happy to see this proposal. Thanks for working on it, @sophieherold ! I like the general approach of starting simple and building from there.
My main two questions are:
What do you expect the comment period to be? I read over the proposal and couldn’t see it mentioned.
How will RFC’s be approved/rejected? The line in the proposal is “The decision is determined by the disposition, specified at the beginning of the final comment period.” “Disposition” here is editors + stakeholders? Does that basically mean that there must be no unresolved concerns from stakeholders for the RFC to be approved?
I’d be interested in contributing some smaller wording changes if that would be helpful. Let me know if you’d like me to follow up with an MR.
Final concerns can be voiced for 14 days, starting from the time the comment was created.
Ideally, any RFC that reaches the final concern period should be advertised—e.g. on This Week in GNOME, and on social media—to catch stragglers, but by this time all issues should have been solved, so the final concern period should be fairly quiet.
My personal position is that an RFC should not be rejected. In order to propose an RFC, people should already have done the work to at least find “sponsors”, and have a rough idea of the feasibility for its implementation—without necessarily having done the implementation work, otherwise it would defeat the point.
An RFC should basically have three states:
discussion: the RFC is still being discussed, and hasn’t reached consensus or stability
active: the RFC has passed the discussion phase and the final concern period
postponed: the RFC has not passed the discussion phase, but it’s clear it might in the future
If somebody proposes an RFC that cannot possibly pass discussion, now or in the future, we should just close the merge request.
From my perspective as a Platform team member, I can come up with a few examples:
New symbolic icons format
GTK added a whole new set of functionality to SVG to formalise symbolic icons, including animations. This introduced changes in how GTK parses SVG, which impacted icon assets embedded by libraries and applications; it also deprecated the “rasterise SVG symbolic assets into PNG with extra data for recoloring” functionality. The additional effect was a series of design changes in the symbolic icons maintained by the design team.
From an RFC perspective, the discussion would have included:
the requirements of the new approach, including missing functionality from existing libraries and tooling
designer feedback
alternatives, like using SVG embedded into fonts instead of plain icons
possible additional tooling for generating and modifying existing assets
The stakeholders would have been: the platform team, the design team, the core apps team, and possibly the documentation team.
Switching from GdkPixbuf to Glycin as the recommended image loader library
Pretty clear case. The requirements for loading images in 2026 are not the same as the ones in 1999, from both a security and a performance perspective.
Since it’s a new library, bindings should also be involved to ensure that the C API is properly exposed and usable. Same goes for the developer documentation.
Stakeholders: platform team, bindings team, documentation team, security team
Switching to a new documentation format for developers documentation
Another fairly clear case.
Since gtk-doc has gone into deep maintenance mode, and we needed a better documentation generator for GTK, we introduced gi-docgen. A proper RFC would have followed for its adoption in the platform team, to outline the goals, effects, and risks associated.
The discussion would have included:
the requirements of various libraries
the porting process from gtk-doc to gi-docgen
the duration of compatibility with gtk-doc
the integration with CI pipelines for publishing documentation
the style format for the API reference
Stakeholders: platform team, documentation team, infrastructure team
These are mainly examples based on things I have direct experience; I’m fairly sure other people and other teams would be able to identify discussions that have happened in the past 5 years that were really informal RFCs.
These are good examples. I think they highlight the need for this rfc process to stay very lightweight, and mainly focused on raising awareness of things that are happening across the projects. I’m pretty sure that none of these things would have happened if there had been a prolonged, concern-heavy discussion of all the eventualities and unlikely failures before any code was written.
And yes, 'informal RFC" is a good way to describe the preliminaries that lead to these initiatives happening. I did talk to the designers at various points about using fonts for symbolic icons, and even wrote prototype code for that approach (there was no interest, so I dropped it). The work on the new symbolic parser(s) in GTK over the past year was done in cooperation with Jakub, so the design team was involved and had a large influence on the direction. But: we could not have written a roadmap for this feature 2 years ago. It would have been totally wrong
The main concern of the RFC process is not to plan ahead—though it is a concern, mainly towards the end of the discussion period, when we want to have something to publicise for other people to pick up in This Week in GNOME or in the release notes. The main concern of an RFC process is to document the discussion, so it’s not sitting on random IRC logs on somebody’s computer, or inside a random Matrix room that nobody can search into 12 months down the line; it’s to document the fact that we did think about the side effects, and the alternatives, so that 5 years down the line somebody doesn’t show up and decides to revert the entire thing because they forgot about the discussion; it’s to make explicit the requirements, so we have a clear picture of what we’re trying to address.
And yes: you will get some RFCs with a prolonged discussion period, and people airdropping themselves into GitLab with random concerns because that’s how FLOSS development goes; the nice bit about the process is that any concern needs to be approved by one of the stakeholders, so you can ignore drive-by comments by architecture astronauts with zero investment.
It’s less of a roadmap and more a declaration of intent, and a summary of why and how.
Something that I’m still mulling over related to the RFC process is: where should the discussion happen.
Using the merge request is an obvious choice, since we’re talking about adding a file to a repository; this works well enough for Rust because GitHub has some moderation tools, albeit entirely rudimental. GitLab, on the other hand, does not even have those, which makes it incredibly easy to get a discussion going completely off the rails.
In theory, we could use Discourse like Python does, and leave the merge request only for the secretarial bits of the process: recording concerns, changing state/stakeholder/editor, etc. This would detach the discussion from the source material a bit, which is not optimal, but at least we’d have a good set of moderation tools.
One reason why I suggested GitLab is that people can subscribe to GitLab labels to get notified about topics. However, since an MR would be created anyway, this would still be the case if the MR just contains a link to the Discourse thread.
However, I’m not sure if Discourse is really superior in moderation to GitLab. In GitLab, accounts are already linked to foundation membership. RFC-0001 already mandates a setup where we can lock the MR while all members can still post. I think achieving this in Discourse would be much harder. Allowed emojis are already limited on GitLab. So I don’t see yet, how Discourse would be superior in this case.
I agree with @ebassi’s examples. Some more controversial examples would be: project wide AI policy, or switching all default branches to ‘main’ where technically possible.
I think rejection should totally stay an option. During a discussion, we, for example, might find some technical reason why a suggestion is a dead end. If there is still a need for something to happen, it might make sense for someone else to take over and write a new RFC, instead of artificially forcing everything into the same RFC. I even think that the existence of competing RFCs might make sense in some situations.
I don’t think a ‘postponed’ state makes sense. It invites us to keep decisions in limbo, which we already have enough examples of in the project. I think there is either an ongoing discussion or the project finds a decision for now.
We also have recently gained this on Discourse as well.
We can split off branches of discussions into separate topics; enable slow mode to de-escalate a contentious discussion; we can hide replies; and we have better moderation mechanisms that target users, as opposed to simply banning them. None of these options are available to GitLab: there you can only delete replies (if you have the maintainer role in the repo), or ban users. Unlike GitHub, you cannot even hide spam/off-topic replies.
From my pov all of these were foregone conclusions. Matthias, Sophie, and you respectively decided to do these things and then you went and did those things. There wasn’t really any outside person that could have stopped you - because you knew the few relevant stakeholders and talked to them in advance and had a plan figured out.
Those examples to me are more a statement of intent and less like an invitation to a discussion, and I would have expected them to go through a process like GNOME / Initiatives · GitLab and not what I usually think of as an RFC process.
Whereas other examples like a projectwide AI policy or (to pick previous discussions) allowing core apps to be written in Rust or if Ptyxis/kgx/gnome-terminal should be the terminal are things that a lot more people can be involved in and have opinions on.
So what I’m wondering is if it makes sense to have the same process for these rather different things.
Perhaps you can clarify what will happen with GNOME/Initiatives. Is it going to be retired? Is it going to be more or less a to-do list only established by an RFC?
Initiatives already are a checklist of random projects that do not match SDK/core/circle projects. We can keep creating tracking issues for porting things, of course, but it has no impact on the actual RFC process.
In favour of GitLab rather than Discourse: commenting on specific parts of the changes makes it easier to have dedicated threads per concern, and to see when each of them have been addressed (thread marked as resolved).