GNOME entwirft einen RFC-Prozess für große technische Entscheidungen

GNOME entscheidet, wie es entscheidet. Sophie Herold, die RFC-Redakteurin des Projekts, hat einen formalen Prozess für große technische Änderungen entworfen, und Phoronix berichtet, dass die Stakeholder ihn nun diskutieren. Heute kann eine wichtige Entscheidung in einem Matrix-Raum fallen und danach verloren gehen. Der Entwurf würde solche Entscheidungen schriftlich festhalten, öffentlich und mit einer Frist.

Der Vorschlag erschien am 27. Juli 2026 im GNOME-Discourse-Forum. Er ist weiterhin ein Vorschlag. Beschlossen ist nichts.

So würde der Prozess funktionieren

Ein RFC ist hier ein Request for Comments: ein schriftlicher Vorschlag, über den öffentlich gestritten wird, bevor sich jemand festlegt. Rust, Python und Kubernetes betreiben Ähnliches.

Der GNOME-Entwurf hat vier bewegliche Teile.

Schritt	Was passiert
Einreichen	Ein Entwickler öffnet den Vorschlag als Merge Request
Zuordnen	Die Redakteure bestimmen die Stakeholder für diesen Bereich
Diskutieren	Der Vorschlag wird auf Discourse debattiert
Entscheiden	Eine 14-tägige Kommentarfrist läuft, dann bewerten Redakteure und Stakeholder

Jeder RFC trägt einen von drei Zuständen: in Diskussion, aktiv oder zurückgestellt. Das Wort "Stakeholder" leistet in diesem Entwurf echte Arbeit. Nur der Einwand eines Stakeholders zählt als blockierender Einwand. Alle dürfen kommentieren, aber nicht jeder Kommentar kann eine Änderung stoppen.

Der Entwurf würde mit sich selbst beschlossen. Fällt die Rückmeldung gut aus, erscheint der Prozess als RFC-0001. Der Merge Request, der ihn enthält, hat derzeit sechs Commits.

Warum GNOME das jetzt will

Das genannte Problem ist Erinnerung, nicht Konflikt. Wichtige Entscheidungen fallen informell, verstreut über IRC-Logs und Matrix-Räume. Diese Orte sind schwer durchsuchbar. Ein Jahr später kann niemand sagen, wer wem zugestimmt hat und warum.

Herolds Vorschlag nennt drei frühere Entscheidungen als Beispiele für Änderungen, die eine schriftliche Aufzeichnung verdient hätten:

• das neue Format für symbolische Icons in GTK
• den Wechsel von GdkPixbuf zur Bildbibliothek Glycin
• die Migration von gtk-doc zu gi-docgen für die Dokumentation

Jede dieser Änderungen veränderte die Arbeit von Menschen außerhalb des Raums, in dem sie beschlossen wurde. Anwendungsentwickler mussten folgen, oft ohne ein Dokument, das die Begründung erklärt.

Emmanuele Bassi aus dem GNOME-Plattformteam lieferte detaillierte Rückmeldungen zum Entwurf. Die Diskussion verlief sachlich statt feindselig.

Der Einwand, den man lesen sollte

Benjamin Otte stellte den Umfang infrage. Er fragte, ob technische Entscheidungen, die ohnehin feststehen ("foregone conclusions"), dieselbe Zeremonie brauchen wie echte Grundsatzfragen.

Dieser Einwand ist der Kern jedes RFC-Prozesses. Schriftliche Verfahren fangen die Entscheidungen ab, die Debatte brauchen. Sie belasten aber auch die, die keine brauchen. Ein Maintainer, der für eine Änderung am Icon-Format einen RFC schreiben muss, ändert es vielleicht einfach nicht. GNOME hat das noch nicht gelöst, und die bisherige Antwort des Entwurfs lautet: Die Redakteure entscheiden, welche Änderungen infrage kommen.

Open-Source-Governance war dieses Jahr ungewöhnlich sichtbar. Debian klärte seine Haltung zu KI-gestützten Beiträgen in einer formalen Abstimmung, während sich das Nixpkgs-Kernteam nach zehn Monaten auflöste und dabei Burnout und Reibungen mit dem Steering Committee nannte. GNOME versucht, Struktur aufzubauen, bevor es sie braucht.

Was das für Entwickler bedeutet

Wenn Sie eine GNOME-Anwendung ausliefern, behalten Sie RFC-0001 im Auge. Sein Ausgang entscheidet, ob künftige Plattformänderungen mit einer lesbaren schriftlichen Begründung ankommen oder als Commit, den Sie entdecken, wenn Ihr Build bricht.

Wenn Sie eine Bibliothek pflegen, von der GNOME abhängt, klären Sie jetzt, ob Sie in Ihrem Bereich als Stakeholder gelten. Nach diesem Entwurf macht genau dieser Status aus Ihrem Einwand mehr als einen Kommentar.

Wenn Sie ein Projekt mit mehr als einer Handvoll Maintainer führen, ist die Durchsuchbarkeit der übertragbare Teil. Sie brauchen nicht GNOMEs genauen Prozess. Sie brauchen Entscheidungen an einem Ort, den ein Neuling in einem Jahr findet - und Chatprotokolle sind das nicht.

Und wenn Sie die Form mitgestalten wollen: Die Diskussion läuft jetzt auf Discourse. Ist RFC-0001 erst beschlossen, erfordert eine Änderung des Prozesses einen RFC über den RFC-Prozess.