Two GNOME threads opened on July twenty seventh, and they belong together. Sophie Herold published a draft for a formal RFC process, the kind of framework that gives project wide decisions a written record instead of a Discourse thread that eventually goes quiet. On the same day, Javad Rahmatzadeh published a reference for large language models generating GNOME Shell extensions, because the extension review queue keeps receiving generated code that repeats the same handful of mistakes. One thread is about how GNOME decides things. The other is about what happens when nobody decided and the submissions arrive anyway.
The short answer
Sophie Herold, working through the GNOME Fellowship program, published a draft RFC process on GNOME Discourse on July twenty seventh, 2026, to give project wide decisions a written path: discussion, a fourteen day final concern period, then active or rejected. Participation is drafted as limited to actively contributing foundation members, and the venue discussion favoured Discourse over GitLab. The same day, Javad Rahmatzadeh published a reference for LLMs generating GNOME Shell extensions, now part of the gjs.guide best practices and downloadable as Markdown, listing the repeated mistakes that fill the extension review queue.
Most free software projects run on an unwritten constitution. Decisions get made by whoever is in the thread, and the record is whichever reply nobody argued with. That works until the questions get bigger than the threads, which is roughly where GNOME is now.
A process, proposed the recursive way
Sophie Herold's draft, published on GNOME Discourse on July twenty seventh through the GNOME Fellowship program, proposes a Request For Comments framework for decisions that span the whole project. The examples in the discussion are the ones you would expect: adopting a new library, changing documentation formats, adopting a programming language, and setting project wide policies, with AI guidelines called out by name.
The shape is familiar to anyone who has read Rust's or Python's process. A written proposal, designated editors, stakeholder teams that have to weigh in, and a defined path to a decision. Emmanuele Bassi described the states an RFC should be able to reach: under discussion, active once the final comment period has closed, or rejected when the idea turns out to be infeasible. A final concern period of fourteen days runs once a proposal has stabilised, and unresolved concerns raised in that window need stakeholder approval before the proposal goes active.
Two questions dominated the replies, and both are the practical kind. Benjamin Otte asked whether one process really suits both a straightforward statement of intent and a genuinely open policy debate, which is the failure mode of every RFC system that has ever been adopted: heavyweight process applied to things that only needed an announcement. The other was venue, GitLab against Discourse, where the discussion leaned to Discourse for its moderation tooling. Participation, as drafted, is restricted to actively contributing foundation members.
If it survives, the proposal becomes RFC-0001 and goes through the process it defines. That recursion is traditional, and it is also a decent smoke test.
The queue that made the case
The second thread from July twenty seventh is less abstract. Javad Rahmatzadeh published an open letter aimed at large language models that generate GNOME Shell extensions, because the review queue for the extensions site keeps filling with generated code exhibiting the same defects over and over.
The list is worth reading if you write extensions at all, because these are not exotic mistakes. Functions wrapped in try and catch for no reason. Redundant type checks and optional chaining sprinkled defensively. A _destroyed boolean flag used to guard lifecycle state instead of overriding destroy(). Connecting to destroy signals rather than overriding the method. Unicode emoji used as interface icons. One monolithic file where modules belong. Placeholder scaffolding with empty enable() and disable() methods. Timeout removal written far from the timeout creation it is supposed to pair with.
What these share is that none of them breaks an extension on the day it is written. They are all maintenance debt: patterns that hide lifecycle bugs, defeat review, and turn into breakage the next time GNOME Shell changes underneath them. Extensions are unusually exposed to that, since they hook into a moving target and get disabled loudly when they stop matching it.
The response is documentation rather than prohibition. The reference has been folded into the gjs.guide best practices pages and is downloadable as Markdown, explicitly so developers can hand it to a model as an instruction file. There is one hard requirement, and it is about publication rather than provenance: an extension generated for personal use should carry a notice saying it should not be uploaded to the extensions site unless the developer understands JavaScript and can maintain it.
That is a narrower line than some projects have drawn. GCC decided in late July to decline significant AI generated contributions except for test cases, and Debian is weighing five separate proposals on AI usage. GNOME's answer, for now, is that the code has to be maintainable by a human who understands it, and how it was produced is that human's problem.
Why both threads matter to anyone shipping an extension
The practical read for extension developers is short. The gjs.guide best practices page is now the reference reviewers are working from, so read it before you submit, whether or not a model wrote your first draft. If you do use one, feed it the Markdown version rather than hoping it has seen enough good GJS in training.
The governance read is slower but more consequential. The extension queue is the clearest current example of a decision GNOME has no formal way to make: nobody has ruled on what quality bar applies, so a single contributor wrote a document and hoped. An RFC process is what turns that into a policy with stakeholders behind it, and the fact that AI guidelines were named as a motivating example in the proposal is not a coincidence. GNOME 51 began its API and ABI freezes around the start of August, which is usually when this kind of question gets oxygen.
Sources and further reading
- GNOME Discourse: proposal for an RFC process
- Draft RFC process document on GNOME GitLab
- An open letter to AI models writing GNOME Shell extensions
- This Week in GNOME, issue 260
- Phoronix: GNOME working to establish an RFC process
- gjs.guide extensions documentation
Frequently asked questions
What would the GNOME RFC process actually cover?
Decisions that are bigger than a merge request and currently have nowhere formal to live. The examples raised in the discussion include architectural shifts such as adopting a new library, changing documentation formats, adopting a programming language, and setting project wide policies, with AI guidelines named explicitly as the kind of policy that needs a process rather than a thread. The mechanism is a written proposal that moves through discussion, gets shepherded by designated editors and stakeholder teams, and ends up either active or rejected. If the idea holds up, the proposal becomes RFC-0001 and runs through its own process, which is the traditional and slightly recursive way these frameworks bootstrap.
How would a proposal get accepted?
Through a comment period rather than a vote. As described by Emmanuele Bassi in the discussion, an RFC should reach one of three states: under discussion, active after the final comment period closes, or rejected if it turns out to be infeasible. Once a proposal is stable, a final concern period of fourteen days runs, and any unresolved concerns raised during it have to be approved by the relevant stakeholders before the RFC becomes active. Participation is drafted as restricted to actively contributing foundation members. The venue was debated between GitLab and Discourse, and the discussion leaned toward Discourse because of its moderation tooling.
What is wrong with AI generated GNOME extensions?
They are usually not broken so much as sloppy in identical ways, which is what makes them exhausting to review. The reference document calls out unnecessary try and catch wrapping around functions, redundant type checks and optional chaining, boolean flags such as _destroyed used to guard lifecycle state instead of overriding destroy(), connecting to destroy signals rather than overriding the method, Unicode emoji used as interface icons, monolithic single file extensions instead of modular ones, placeholder code with empty enable() and disable() methods, and timeout removal written far away from the timeout creation it pairs with. None of these makes an extension fail on the first run. All of them make it a liability once GNOME Shell changes underneath it.
Is GNOME banning AI generated extensions?
No. The approach in the reference is to raise the floor rather than to police the origin. It documents what a correct extension looks like, has been folded into the gjs.guide best practices documentation, and is offered as a downloadable Markdown file so developers can hand it to a model as an instruction file. The one firm line concerns publication: generated extensions written for personal use should carry a notice saying they should not be uploaded to the extensions site unless the developer understands JavaScript and can maintain the code. That is a maintainability requirement, not a provenance rule, and it is a different posture from projects that have chosen to decline AI generated contributions outright.
Why do these two stories belong in the same article?
Because the second is the argument for the first. The extension queue problem is precisely the sort of thing a project needs a written policy for: what quality bar applies, who enforces it, what a reviewer is entitled to reject. Right now the answer lives in a blog post and a documentation page written by one contributor who got tired of reviewing the same mistakes. An RFC process is the machinery that would turn that into a decision with stakeholders attached to it. GNOME 51 also began its API and ABI freezes around the start of August, which is the usual moment when governance questions get attention because the code has stopped moving.