Deux fils GNOME se sont ouverts le vingt sept juillet, et ils vont ensemble. Sophie Herold a publié un brouillon de processus RFC formel, le genre de cadre qui donne aux décisions à l'échelle du projet une trace écrite plutôt qu'un fil Discourse qui finit par s'éteindre. Le même jour, Javad Rahmatzadeh a publié une référence destinée aux grands modèles de langage qui produisent des extensions GNOME Shell, parce que la file de relecture reçoit sans cesse du code généré répétant la même poignée d'erreurs. Un fil traite de la façon dont GNOME décide. L'autre, de ce qui arrive quand personne n'a décidé et que les soumissions affluent quand même.
The short answer
Sophie Herold, dans le cadre du programme GNOME Fellowship, a publié un brouillon de processus RFC sur GNOME Discourse le vingt sept juillet 2026, pour donner aux décisions du projet un chemin écrit : discussion, période de préoccupations finales de quatorze jours, puis active ou rejetée. La participation est écrite comme réservée aux membres de la fondation contribuant activement, et la discussion sur le lieu a penché pour Discourse plutôt que GitLab. Le même jour, Javad Rahmatzadeh a publié une référence pour les modèles générant des extensions GNOME Shell, désormais intégrée aux bonnes pratiques gjs.guide et téléchargeable en Markdown, qui liste les erreurs répétées remplissant la file de relecture.
La plupart des projets libres vivent sur une constitution non écrite. Les décisions se prennent entre les personnes présentes dans le fil, et la trace, c'est la réponse que personne n'a contestée. Cela fonctionne jusqu'à ce que les questions dépassent la taille des fils, et c'est à peu près là que GNOME se trouve.
Un processus, proposé de façon récursive
Le brouillon de Sophie Herold, publié sur GNOME Discourse le vingt sept juillet dans le cadre du programme GNOME Fellowship, propose un cadre de type Request For Comments pour les décisions qui engagent tout le projet. Les exemples de la discussion sont ceux que l'on attend : adopter une nouvelle bibliothèque, changer de format de documentation, adopter un langage de programmation, fixer des politiques à l'échelle du projet, les lignes directrices sur l'IA étant nommément citées.
La forme parlera à qui a lu le processus de Rust ou de Python. Une proposition écrite, des éditeurs désignés, des équipes parties prenantes qui doivent se prononcer, et un chemin défini vers une décision. Emmanuele Bassi a décrit les états qu'une RFC doit pouvoir atteindre : en discussion, active une fois la période de commentaires finale close, ou rejetée si l'idée s'avère irréalisable. Une période de préoccupations finales de quatorze jours s'ouvre lorsqu'une proposition s'est stabilisée, et les préoccupations non résolues soulevées dans cette fenêtre demandent l'approbation des parties prenantes avant le passage à l'état actif.
Deux questions ont dominé les réponses, toutes deux très concrètes. Benjamin Otte a demandé si un processus unique convenait à la fois à une simple déclaration d'intention et à un débat de politique réellement ouvert, ce qui est le mode d'échec de tous les systèmes de RFC jamais adoptés : un cadre lourd appliqué à ce qui ne demandait qu'une annonce. L'autre portait sur le lieu, GitLab contre Discourse, avec une inclinaison pour Discourse et ses outils de modération. La participation, telle qu'écrite, se limite aux membres de la fondation qui contribuent activement.
Si elle survit, la proposition deviendra RFC-0001 et passera par le processus qu'elle définit. Cette récursion est une tradition, et c'est aussi un test de fumée honnête.
La file d'attente qui a fait la démonstration
Le second fil du vingt sept juillet est nettement moins abstrait. Javad Rahmatzadeh a publié une lettre ouverte adressée aux grands modèles de langage qui produisent des extensions GNOME Shell, parce que la file de relecture du site des extensions se remplit de code généré présentant les mêmes défauts, encore et encore.
La liste mérite la lecture si vous écrivez des extensions, car ce ne sont pas des erreurs exotiques. Des fonctions enveloppées dans des try et catch sans raison. Des vérifications de type redondantes et du chaînage optionnel semés par réflexe défensif. Un drapeau booléen _destroyed pour garder l'état du cycle de vie au lieu de redéfinir destroy(). Une connexion aux signaux de destruction plutôt que la redéfinition de la méthode. Des émojis Unicode en guise d'icônes d'interface. Un fichier monolithique là où des modules s'imposent. Une ossature de code avec des méthodes enable() et disable() vides. La suppression d'un délai écrite très loin de la création qu'elle est censée accompagner.
Leur point commun : aucune ne casse une extension le jour où elle est écrite. Ce sont des dettes de maintenance, des motifs qui masquent les bugs de cycle de vie, qui découragent la relecture, et qui se transforment en panne à la prochaine évolution de GNOME Shell. Les extensions y sont particulièrement exposées, puisqu'elles s'accrochent à une cible mouvante et se font désactiver bruyamment dès qu'elles ne correspondent plus.
La réponse relève de la documentation, pas de l'interdiction. La référence a été intégrée aux pages de bonnes pratiques gjs.guide et se télécharge en Markdown, précisément pour qu'un développeur puisse la fournir à un modèle comme fichier d'instructions. Une seule exigence est ferme, et elle porte sur la publication plutôt que sur l'origine : une extension générée pour un usage personnel doit porter une mention indiquant qu'elle ne devrait pas être déposée sur le site des extensions si son auteur ne comprend pas JavaScript et ne peut pas la maintenir.
C'est une ligne plus étroite que celle tracée par d'autres projets. GCC a décidé fin juillet de refuser les contributions significatives générées par IA, à l'exception des cas de test, et Debian pèse cinq propositions distinctes sur l'usage de l'IA. La réponse de GNOME, pour l'instant, tient en ceci : le code doit être maintenable par un humain qui le comprend, et sa méthode de production regarde cet humain là.
Ce que cela change pour qui publie une extension
La lecture pratique est courte. La page de bonnes pratiques gjs.guide est désormais la référence dont partent les relecteurs, alors lisez la avant de soumettre, qu'un modèle ait écrit votre premier jet ou non. Si vous en utilisez un, donnez lui la version Markdown plutôt que d'espérer qu'il ait vu assez de bon GJS pendant son entraînement.
La lecture de gouvernance est plus lente et plus lourde de conséquences. La file d'extensions est l'exemple le plus net d'une décision que GNOME n'a aucun moyen formel de prendre : personne n'a tranché sur le niveau de qualité exigible, alors un contributeur seul a écrit un document et a espéré. Un processus RFC est ce qui transformerait cela en politique adossée à des parties prenantes, et le fait que les lignes directrices sur l'IA soient citées comme exemple motivant dans la proposition n'a rien d'un hasard. GNOME 51 a entamé ses gels d'API et d'ABI vers le début du mois d'août, la période où ce genre de question retrouve de l'air.
Sources et pour aller plus loin
- GNOME Discourse : proposition d'un processus RFC
- Brouillon du processus RFC sur le GitLab de GNOME
- Lettre ouverte aux modèles qui écrivent des extensions GNOME Shell
- This Week in GNOME, numéro 260
- Phoronix : GNOME travaille à établir un processus RFC
- Documentation des extensions sur gjs.guide
Questions fréquentes
Que couvrirait réellement le processus RFC de GNOME ?
Les décisions plus larges qu'une demande de fusion et qui n'ont aujourd'hui aucun lieu formel où exister. Les exemples cités dans la discussion incluent les virages d'architecture comme l'adoption d'une nouvelle bibliothèque, le changement de format de documentation, l'adoption d'un langage de programmation, et la définition de politiques à l'échelle du projet, les lignes directrices sur l'IA étant nommées explicitement comme le type de politique qui exige un processus plutôt qu'un fil de discussion. Le mécanisme repose sur une proposition écrite qui traverse une phase de discussion, encadrée par des éditeurs désignés et des équipes parties prenantes, et qui finit active ou rejetée. Si l'idée tient, la proposition devient RFC-0001 et passe par son propre processus, la manière traditionnelle et légèrement récursive dont ces cadres s'amorcent.
Comment une proposition serait elle acceptée ?
Par une période de commentaires plutôt que par un vote. Comme l'a décrit Emmanuele Bassi dans la discussion, une RFC doit pouvoir atteindre trois états : en discussion, active une fois la période de commentaires finale close, ou rejetée si l'idée se révèle irréalisable. Quand une proposition s'est stabilisée, une période de préoccupations finales de quatorze jours s'ouvre, et toute préoccupation non résolue soulevée pendant cette fenêtre doit être approuvée par les parties prenantes concernées avant que la RFC ne devienne active. La participation est écrite comme réservée aux membres de la fondation qui contribuent activement. Le lieu a fait débat entre GitLab et Discourse, et la discussion a penché vers Discourse pour ses outils de modération.
Qu'est ce qui cloche dans les extensions GNOME générées par IA ?
Elles sont moins cassées que négligées, et toujours de la même façon, ce qui les rend épuisantes à relire. Le document de référence pointe l'enveloppement inutile de fonctions dans des try et catch, les vérifications de type redondantes et le chaînage optionnel défensif, les drapeaux booléens du type _destroyed employés pour garder l'état du cycle de vie au lieu de redéfinir destroy(), la connexion aux signaux de destruction plutôt que la redéfinition de la méthode, les émojis Unicode utilisés comme icônes d'interface, les extensions monolithiques d'un seul fichier au lieu d'un découpage en modules, le code d'ossature avec des méthodes enable() et disable() vides, et la suppression d'un délai écrite très loin de sa création. Aucun de ces défauts ne fait échouer une extension au premier lancement. Tous en font un fardeau dès que GNOME Shell bouge en dessous.
GNOME interdit il les extensions générées par IA ?
Non. L'approche de la référence consiste à relever le plancher plutôt qu'à contrôler l'origine. Elle documente à quoi ressemble une extension correcte, a été intégrée à la documentation des bonnes pratiques gjs.guide, et est proposée en fichier Markdown téléchargeable pour que les développeurs puissent la donner à un modèle comme fichier d'instructions. La seule ligne ferme concerne la publication : une extension générée pour un usage personnel doit porter une mention indiquant qu'elle ne devrait pas être déposée sur le site des extensions si le développeur ne comprend pas JavaScript et ne peut pas en assurer la maintenance. C'est une exigence de maintenabilité, pas une règle de provenance, et c'est une posture différente de celle des projets qui ont choisi de refuser purement et simplement les contributions générées.
Pourquoi ces deux sujets tiennent ils dans le même article ?
Parce que le second est l'argument du premier. Le problème de la file d'extensions est exactement le genre de sujet qui réclame une politique écrite : quel niveau de qualité s'applique, qui le fait respecter, ce qu'un relecteur est en droit de refuser. Aujourd'hui la réponse tient dans un billet de blog et une page de documentation rédigés par un contributeur lassé de relire les mêmes erreurs. Un processus RFC est la mécanique qui transformerait cela en décision avec des parties prenantes derrière. GNOME 51 a par ailleurs entamé ses gels d'API et d'ABI vers le début du mois d'août, le moment habituel où les questions de gouvernance retrouvent de l'attention parce que le code a cessé de bouger.