Zusammenfassung

  • Das RFC Production Center lässt Autoren in einem freiwilligen Pilotversuch redaktionelle Änderungen während der Schlussprüfung in einem GitHub-Pull-Request sehen. Sein Bericht vom 30. September 2026 nennt 31 Dokumente in der Warteschlange, deren Autoren teilnehmen wollten, und eine Aufnahmegrenze von fünf Dokumenten pro Monat. Beides sind Angaben zum damaligen Stand.
  • Der veröffentlichte Ablauf sieht nach der Klärung der Änderungen einen Merge vor, dann die abschließende Zustimmung des Autors per E-Mail und schließlich das Kopieren der Quelldatei auf das Dateisystem des Centers. Eine gemeinsame Versionskennung für alle drei Schritte beschreibt die Roadmap nicht.

Drei Belege für einen Satz

Am Ende der RFC-Produktion geht es auch um ein Komma. Ein Redakteur verschiebt es; der Autor prüft, ob die technische Aussage erhalten bleibt. In der bisherigen E-Mail-Schlussprüfung konnte diese Entscheidung über Nachrichten und Anhänge verteilt liegen. Der Oktoberbericht des RFC Production Center, verschickt am 30. September, beschreibt einen freiwilligen Versuch, redaktionelle Änderungen stattdessen in GitHub sichtbar zu machen. Die E-Mail-Schlussprüfung bleibt ebenfalls verfügbar.

Die GitHub-Roadmap des Centers beschreibt die erste Stufe recht genau. Das Center legt für ein Dokument ein Repository an, speichert die angenommene Quelle in einem approved-Zweig und stellt seine Änderungen in einem Zweig für Vorschläge als Pull Request daneben. Autoren können Unterschiede direkt lesen und Fragen an der betroffenen Stelle besprechen. Sobald die Probleme geklärt sind, wird der Vorschlag zusammengeführt. Der Autor gibt seine endgültige Zustimmung trotzdem per E-Mail. Danach kopiert das Center die fertige Quelle auf sein Dateisystem zur Veröffentlichung.

Damit entstehen drei Belege mit unterschiedlichen Aufgaben. Der Pull Request erklärt, was sich geändert hat. Die Nachricht bestätigt, dass der Autor die endgültige Fassung billigt. Die Datei im Publikationssystem bestimmt, was später als RFC erscheint. Ein Merge ist kein Ersatz für die Zustimmung, und eine Zustimmung zu einer Fassung ist keine Zustimmung zu jeder späteren Datei mit ähnlichem Namen. Die öffentliche Roadmap sagt nicht, welche unveränderliche Kennung oder Prüfsumme diese drei Schritte miteinander verbindet. Das ist eine konkrete Lücke in der Beschreibung, kein Befund über einen falsch veröffentlichten RFC.

Fünf Plätze und 31 Interessenten

Für den GitHub-Versuch setzt das Center eine Grenze von fünf Dokumenten je Monat. Im Bericht vom 30. September hatten die Autoren von 31 Dokumenten in der Warteschlange ihre Teilnahme zugesagt; für Oktober sollten fünf aufgenommen werden können. Diese Zahlen zeigen Interesse und einen bewusst kleinen Durchsatz. Sie sagen nichts Verlässliches über die heutige Warteschlange oder die Wartezeit eines bestimmten Dokuments. Dazu fehlten Eingangsreihenfolge, tatsächliche Aufnahmen und Abschlüsse.

Im selben Bericht steht eine zweite Zahl: 23 Dokumente für einen eigenen kramdown-rfc-Versuch mit ebenfalls fünf Aufnahmen pro Monat. Hier geht es um das Eingabeformat, beim GitHub-Versuch um die Schlussprüfung. Wie viele Dokumente zu beiden Gruppen gehören, wird nicht angegeben. Wer 31 und 23 addiert, erfindet eine gemeinsame Warteschlange. Die beiden Grenzen messen verschiedene Experimente.

Das Center kann aus fünf Fällen im Monat lernen, ohne die gesamte Produktion auf einmal umzustellen. Interessant ist aber nicht nur, wie viele Pull Requests eröffnet werden. Zu zählen wären auch abgeschlossene Autorprüfungen und tatsächlich veröffentlichte RFCs. Solche Übergänge machen sichtbar, ob die kleine Aufnahmegrenze den Ablauf verbessert oder bloß einen hübsch dokumentierten Rückstau erzeugt.

Eine zweite Prüfung nach der Umwandlung

Bei Quellen im Format kramdown-rfc sieht die Roadmap nach der Umwandlung in RFCXML einen weiteren Pull Request vor. Autoren sollen auch die Formatierungsunterschiede sehen. Das ist ein eigener Übergang: Der erste Vergleich betrifft redaktionelle Änderungen am angenommenen Text, der zweite die Form, in der er veröffentlicht werden soll. Selbst ein unveränderter technischer Satz kann im endgültigen Dokument anders gegliedert oder dargestellt sein.

Die Roadmap zieht noch eine Grenze. Will ein Autor Änderungen, die über die Vorschläge des Centers hinausgehen, soll er einen getrennten Pull Request erstellen; je nach Fall kann eine Genehmigung des zuständigen Stream-Managers per E-Mail nötig sein. Der Redaktionstisch darf also nicht unbemerkt zum Ort neuer technischer Entscheidungen werden. Gerade deshalb muss die genehmigte Fassung beim letzten Kopieren erkennbar bleiben.

Spätere Roadmap-Phasen sprechen von internen privaten Repositories und weiteren Publikationsschritten. Zustimmungen der Autoren und IANA-Vorgänge sollen dort über das Produktionswerkzeug Purple laufen, nicht einfach über GitHub-Aktionen. Die direkte Zusammenarbeit der Autoren in GitHub ist als spätere Aufgabe vermerkt. Eine Roadmap ist kein Betriebsprotokoll: Der belegte Pilot ist die freiwillige Schlussprüfung mit der beschriebenen Aufnahmegrenze.