GNOME is introducing a formal RFC process for significant project decisions. Proposals will be written up, circulated, discussed in a defined venue, and resolved on the record.

This sounds like process overhead. For a project GNOME’s size it is closer to overdue.

The problem it addresses

GNOME has made a series of decisions in recent years that materially affected a large number of users and downstream projects: the X11 session removal, the long march of design changes, the shape of the extensions API, accessibility priorities.

Each was discussed somewhere. The difficulty was that “somewhere” varied: a GitLab issue here, a mailing list thread there, a discussion at GUADEC, a blog post that turned out to be the authoritative statement. If you were not already embedded in the project, there was frequently no way to know a decision was being made until it was made.

That produces two recurring failures. Downstream maintainers get surprised by changes they could have planned for. And the subsequent public argument tends to be about process legitimacy rather than about the technical merits, because nobody can point to where the decision was supposed to have been made.

Writing proposals down and resolving them in a known place fixes the second problem directly and helps considerably with the first.

The model

RFC processes are well established elsewhere. Rust’s has been running for years and is generally considered a success: a written proposal, a public comment period, a decision by the relevant team, and a permanent record of what was decided and why.

The advantages transfer. A written proposal forces the author to articulate the motivation and the alternatives considered, which improves proposals before anyone else reads them. A defined comment window means objections arrive during the design rather than after the release. And the archive means that in three years, when someone asks why GNOME does something a particular way, the answer exists.

The costs also transfer. RFC processes add latency, they favour contributors who write well in English, and they can become a bureaucratic obstacle that discourages exactly the small improvements a project wants. Rust has felt all of these.

What to watch

The question that determines whether this works is scope: which decisions require an RFC. Too broad and routine work stalls. Too narrow and the consequential decisions keep happening outside the process, which is worse than not having one, because the process then provides legitimacy without accountability.

The second question is whether the outcomes actually bind. A process that produces recommendations which are then overridden elsewhere will be abandoned quickly and cynically.

For downstream distributions and for developers of extensions and applications, the practical upside is predictability. Knowing where to look for pending changes that will affect you is worth a lot, and GNOME has not previously offered a reliable answer to that question.

GNOME 51 is currently in beta, so the first substantial test of this will likely be a cycle or two out.