Ein Release Candidate ist keine Nachricht, ein Forenthread keine Entscheidung
Serguey Asael Shinder2 Min. LesezeitDieses Ressort wird überwiegend von den Projekten selbst gespeist: Bäume mit Improvement Proposals, Client-Repositories, Blogs von Stiftungen, Governance-Foren. Das ist gewollt — ein angenommener Vorschlag oder ein getaggtes Release ist das Ereignis, und Fachberichterstattung ist der Zeiger darauf. Es erzeugt aber auch ein spezifisches Problem, sichtbar schon am ersten Tag dieser Seite: Die Feeds liefern viel Bewegung und vergleichsweise wenig Ereignis.
Vier Prüfungen trennen beides, und sie kosten fast nichts.
Ein Release Candidate ist kein Release. Am Eröffnungstag waren die neuesten Einträge zweier Chains v1.15.0-rc.3 und v1.15.0-rc.4, wenige Stunden auseinander. Ein rc ist eine Einladung zum Testen. Als Nachricht aufgeschrieben ergibt das einen Text, der mit rc.5 veraltet ist — und lehrt die Lesenden, dass unsere Überschriften nichts bedeuten. Das Ressort blieb stattdessen leer, und das ist das ehrliche Ergebnis.
Ein Forenthread ist keine Entscheidung. In Governance-Foren wird gestritten, und der Streit ist oft interessanter als das Ergebnis — aber ein Beitrag ist die Position einer Teilnehmerin. Die Entscheidung steht im Vorschlagsdokument und im Client-Release, das ihn umsetzt. Wo wir ein Forum zitieren, steht im Text, dass es ein Forum ist.
Ein Statusfeld schlägt jede Überschrift. Jedes Vorschlagssystem führt eines: Draft, Review, Accepted, Final. Es ist das Verlässlichste im Dokument und das, was in der Berichterstattung am häufigsten wegfällt. Eine Änderung, die als kommend beschrieben wird, deren Vorschlag aber Draft trägt und einen leeren Feature-Key hat, ist ein Plan — und das gehört in den Satz, der den Plan beschreibt, nicht in eine Fußnote am Ende.
Ein Commit ist nur dann ein Ereignis, wenn er ändert, was Implementierende tun müssen. Repository-Feeds liefern jeden Merge. Die meisten sind redaktionell. Notierenswert sind die, die eine Regel ändern: ein Skalar, der jetzt reduziert werden muss, ein Limit, das von einer Zahl auf eine andere steigt, ein Vorschlag, der von einer Liste in eine andere wandert. Die Prüfung lautet: Muss deswegen jemand Code oder einen Plan ändern?
Das ist kein Aufruf zum Schweigen — und auch kein Freibrief, ein Ressort leer zu lassen. Auf die Warteschlange eines einzigen Tages angewandt, verwarfen diese Prüfungen ein Dutzend Release Candidates, ein tägliches Social-Digest und mehrere Threads. Auf eine Ablehnung folgt keine leere Seite, sondern der Gang zum Projekt selbst. Zwei Ressorts hatten nichts in der Warteschlange und ein echtes, datiertes Release auf der Release-Seite des Projekts — daher stammen sie. Die Regel dieses Ressorts sind beide Hälften zugleich: jedes Ressort bekommt etwas, und keines wird mit rc.4 gefüllt.