GNOME drafts an RFC process for big technical decisions

GNOME is deciding how it will decide. Sophie Herold, the project's RFC editor, has drafted a formal process for major technical changes, and Phoronix reports that stakeholders are now discussing it. Today a big call can be settled in a Matrix room and then lost. The draft would put those calls in writing, in public, with a deadline.

The proposal went up on GNOME's Discourse forum on 27 July 2026. It is still a proposal. Nothing has been adopted.

How the process would work

An RFC here is a Request for Comments: a written proposal that people argue about in the open before anyone commits to it. Rust, Python and Kubernetes all run something similar.

GNOME's draft has four moving parts.

Step	What happens
Submit	A developer opens the proposal as a merge request
Identify	Editors work out who the stakeholders are for that area
Discuss	The proposal is debated on Discourse
Decide	A 14-day final comment period runs, then editors and stakeholders assess

Each RFC carries one of three states: discussion, active, or postponed. The word "stakeholder" is doing real work in this design. Only a stakeholder's concern counts as a blocking objection. Everyone can comment, but not every comment can stop a change.

The draft would be adopted using itself. If the feedback is good, the process ships as RFC-0001. The merge request holding it currently has six commits.

Why GNOME wants it now

The stated problem is memory, not conflict. Important decisions happen informally, across IRC logs and Matrix rooms. Those places are hard to search. A year later, nobody can say who agreed to what, or why.

Herold's proposal names three past decisions as examples of changes that deserved a written record:

• the new symbolic icons format in GTK
• the switch from GdkPixbuf to the Glycin image library
• the migration from gtk-doc to gi-docgen for documentation

Each of those changed work for people outside the room where it was decided. Application developers had to follow, often without a document explaining the reasoning.

Emmanuele Bassi, from GNOME's platform team, gave detailed input on the design. The discussion has been substantive rather than hostile.

The objection worth reading

Benjamin Otte pushed back on scope. He questioned whether technical decisions that are already "foregone conclusions" need the same ceremony as genuine policy questions.

That objection is the crux of every RFC process. Written processes catch the decisions that need debate. They also tax the ones that do not. A maintainer who has to write an RFC to change an icon format may simply not change it. GNOME has not resolved this yet, and the draft's answer so far is to let editors judge which changes qualify.

Open-source governance has been unusually visible this year. Debian settled its position on AI-assisted contributions by a formal vote, while the Nixpkgs core team disbanded after ten months, citing burnout and friction with its steering committee. GNOME is trying to build structure before it needs it.

What this means for developers

If you ship a GNOME application, watch RFC-0001. Its outcome decides whether future platform changes arrive with a written rationale you can read, or as a commit you discover when your build breaks.

If you maintain a library that GNOME depends on, find out now whether you count as a stakeholder in your area. Under this draft, that status is what turns your objection from a comment into a blocker.

If you run any project with more than a handful of maintainers, the searchability argument is the transferable part. You do not need GNOME's exact process. You do need decisions to live somewhere a newcomer can find in a year, which chat logs are not.

And if you want to influence the shape of it, the discussion is open on Discourse now. Once RFC-0001 is adopted, changing the process will mean filing an RFC about the RFC process.