GNOME rédige un processus RFC pour ses grandes décisions techniques

GNOME décide comment il décide. Sophie Herold, éditrice RFC du projet, a rédigé un processus formel pour les changements techniques majeurs, et Phoronix rapporte que les parties prenantes en discutent. Aujourd'hui, une décision importante peut se prendre dans un salon Matrix, puis disparaître. Le projet mettrait ces décisions par écrit, en public, avec une échéance.

La proposition a été publiée le 27 juillet 2026 sur le forum Discourse de GNOME. Elle reste une proposition. Rien n'a été adopté.

Comment le processus fonctionnerait

Un RFC, ici, est un Request for Comments : une proposition écrite dont on débat en public avant que quiconque ne s'engage. Rust, Python et Kubernetes utilisent un mécanisme comparable.

Le projet comporte quatre étapes.

Étape	Ce qui se passe
Soumettre	Un développeur ouvre la proposition sous forme de merge request
Identifier	Les éditeurs déterminent les parties prenantes du domaine concerné
Discuter	La proposition est débattue sur Discourse
Décider	Une période finale de commentaires de 14 jours s'ouvre, puis éditeurs et parties prenantes tranchent

Chaque RFC porte l'un de trois états : en discussion, actif ou reporté. Le mot « partie prenante » joue ici un vrai rôle. Seule l'objection d'une partie prenante compte comme objection bloquante. Tout le monde peut commenter, mais tous les commentaires ne peuvent pas arrêter un changement.

Le projet serait adopté en s'appliquant à lui-même. Si les retours sont bons, il devient RFC-0001. La merge request qui le contient compte aujourd'hui six commits.

Pourquoi GNOME veut cela maintenant

Le problème évoqué est celui de la mémoire, pas du conflit. Les décisions importantes se prennent de façon informelle, dispersées entre journaux IRC et salons Matrix. Ces endroits se cherchent mal. Un an plus tard, personne ne peut dire qui a accepté quoi, ni pourquoi.

La proposition de Herold cite trois décisions passées comme exemples de changements qui méritaient une trace écrite :

• le nouveau format d'icônes symboliques dans GTK
• le passage de GdkPixbuf à la bibliothèque d'images Glycin
• la migration de gtk-doc vers gi-docgen pour la documentation

Chacune a modifié le travail de personnes extérieures à la salle où elle avait été décidée. Les développeurs d'applications ont dû suivre, souvent sans document expliquant le raisonnement.

Emmanuele Bassi, de l'équipe plateforme de GNOME, a apporté des remarques détaillées sur la conception. La discussion a été argumentée plutôt qu'hostile.

L'objection qui mérite lecture

Benjamin Otte a contesté le périmètre. Il a demandé si des décisions techniques déjà acquises d'avance méritent le même cérémonial que de véritables questions de politique.

Cette objection est le nœud de tout processus RFC. Une procédure écrite attrape les décisions qui exigent un débat. Elle taxe aussi celles qui n'en ont pas besoin. Un mainteneur obligé d'écrire un RFC pour changer un format d'icônes ne le changera peut-être pas du tout. GNOME n'a pas encore tranché, et la réponse actuelle du projet consiste à laisser les éditeurs juger quels changements sont concernés.

La gouvernance open source a été particulièrement visible cette année. Debian a fixé sa position sur les contributions assistées par IA par un vote formel, tandis que l'équipe centrale de Nixpkgs s'est dissoute au bout de dix mois, invoquant l'épuisement et des frictions avec son comité de pilotage. GNOME tente de construire une structure avant d'en avoir besoin.

Ce que cela signifie pour les développeurs

Si vous publiez une application GNOME, surveillez RFC-0001. Son issue déterminera si les futurs changements de plateforme arrivent avec une justification écrite que vous pouvez lire, ou sous forme d'un commit que vous découvrez quand votre build casse.

Si vous maintenez une bibliothèque dont GNOME dépend, vérifiez dès maintenant si vous comptez comme partie prenante dans votre domaine. Selon ce projet, c'est ce statut qui transforme votre objection en blocage plutôt qu'en simple commentaire.

Si vous dirigez un projet comptant plus d'une poignée de mainteneurs, l'argument transposable est celui de la recherche. Vous n'avez pas besoin du processus exact de GNOME. Vous avez besoin que les décisions vivent quelque part où un nouveau venu les retrouvera dans un an, ce que les journaux de discussion ne permettent pas.

Et si vous voulez peser sur sa forme, la discussion est ouverte sur Discourse dès maintenant. Une fois RFC-0001 adopté, modifier le processus supposera de déposer un RFC sur le processus RFC.