{"id":183253,"date":"2026-09-05T16:53:29","date_gmt":"2026-09-05T14:53:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/reformirovanie-proczessa-utverzhdeniya-znachitelnyh-izmenenij-v-gnome"},"modified":"2026-09-05T16:53:33","modified_gmt":"2026-09-05T14:53:33","slug":"reforming-the-approval-process-for-major-changes-in-gnome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/reforming-the-approval-process-for-major-changes-in-gnome","title":{"rendered":"Umgestaltung des Freigabeprozesses f\u00fcr wesentliche \u00c4nderungen in GNOME","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Entwickler von GNOME diskutieren die Einf\u00fchrung eines neuen Entscheidungsprozesses, der auf der Ver\u00f6ffentlichung von Vorschl\u00e4gen in Form von RFC (Request for Comments) und deren anschlie\u00dfender gemeinsamer Genehmigung basiert. Die Mitglieder der GNOME Foundation werden eingeladen, sich an der Diskussion zu beteiligen und ihre Anmerkungen bis zum 4. Oktober abzugeben. Das RFC-basierte Modell soll nur in besonderen F\u00e4llen angewendet werden, um festgefahrene Situationen zu l\u00f6sen, globale \u00c4nderungen im Projekt zu genehmigen, die die Arbeitsmethoden der Teilnehmer oder den Code verschiedener Anwendungen und Subsysteme betreffen, sowie architektonische \u00c4nderungen und umfangreiche \u00dcberarbeitungen der Benutzeroberfl\u00e4che. <\/p>\n
Es wird erw\u00e4hnt, dass das derzeit praktizierte informelle Modell, das auf individuellen Entscheidungen basiert, zu Burnout der Teilnehmer, langwierigen Streitigkeiten und erm\u00fcdenden Konsenssuchungen in Chats f\u00fchrt. Das neue Modell bietet eine strenge Regelung zur Erh\u00f6hung der Transparenz, Strukturierung des Prozesses und \u00dcbergang zu kollektiver Verantwortung f\u00fcr Entscheidungen anstelle pers\u00f6nlicher Verantwortung. Zu den Nachteilen des RFC-basierten Managementmodells geh\u00f6rt die Komplexit\u00e4t des Prozesses f\u00fcr einige Entwickler und das Fehlen eines Mechanismus zur Konfliktbew\u00e4ltigung, der zu einer Blockade wichtiger RFCs f\u00fchrt. <\/p>\n
Phasen der RFC-F\u00f6rderung: <\/p>\n
\n
Einreichung der Datei RFC-XXXX-titel.md im GNOME\/rfcs-Repository mit einem strukturiert ausgearbeiteten Vorschlag und einem Link zur Diskussion.\n
Diskussion des Vorschlags auf der Plattform Discourse mit gleichzeitiger Bearbeitung und Anpassung des RFC.\n
Die Ver\u00f6ffentlichung von Einw\u00e4nden durch Teilnehmer mit dem Vermerk «**Concern**», die m\u00f6gliche Probleme beschreiben oder alternative L\u00f6sungswege vorschlagen. Im Falle der Unterst\u00fctzung des Einwands durch den Redakteur oder einen der beteiligten Teilnehmer wird dieser in die Kategorie der verpflichtend zu pr\u00fcfenden Einw\u00e4nde umgewandelt.\n
Pr\u00fcfung der ge\u00e4u\u00dferten Einw\u00e4nde, Erarbeitung von Ma\u00dfnahmen zu deren Behebung und \u00c4nderung des RFC.\n
Nach Abschluss der Diskussion und Pr\u00fcfung der Einw\u00e4nde wird eine 14-t\u00e4gige finale Kommentierungsphase (FCP, Final Comment Period) angek\u00fcndigt, in der nur neue Einw\u00e4nde ge\u00e4u\u00dfert werden k\u00f6nnen. Wenn ein neuer Einwand angenommen wird, wird die Diskussion neu gestartet und die Frist f\u00fcr den finalen Empfang von Einw\u00e4nden verschoben.\n
Nach Ende der finalen Kommentierungsphase und der Kl\u00e4rung aller Einw\u00e4nde wird der RFC entweder angenommen oder abgelehnt. <\/ul>\n