Zusammenfassung

  • Die veröffentlichten Apache-Regeln unterscheiden das qualifizierte Veto gegen eine Codeänderung, die formelle Paketfreigabe, die Projektbefugnis des PMC und die körperschaftliche Board-Aufsicht.
  • Ein Befugnisnachweis soll Handlung, Artefakt, bindenden Kreis, Regel, Einwände, Ergebnis und einen gesonderten Körperschaftsakt verbinden, statt Commit, Abstimmung und Board-Aufmerksamkeit gleichzusetzen.

Ein kurzer Satz kann verschiedene Entscheidungen verdecken

„Apache hat es genehmigt“ kann einen Commit, eine Listen-Diskussion, eine Release-Abstimmung, einen PMC-Beschluss, eine Board Resolution oder bloß eine Frage zu einem Quartalsbericht meinen. Die ASF-Governance behandelt diese Tatsachen nicht als Synonyme. Technische und gemeinschaftliche Richtung liegen beim jeweiligen PMC; Vermögen, Ämter, Gesamtpolitik und Aufsicht liegen auf der Ebene der Foundation.

Zuerst ist also nach der Handlung zu fragen. Ein Repository-Update ist eine technische Handlung. Ein genau bestimmtes Artefakt als offizielles Release auszugeben, ist ein PMC-Akt. Einen Officer zu ernennen, eine Resolution zu fassen oder einen Bericht zu prüfen, ist ein Körperschaftsakt. Dieselbe Person kann Rollen verbinden, aber ihre Biografie erweitert nicht die Befugnis einer einzelnen Handlung.

Commit-Zugang ist keine formelle Release-Befugnis

Der PMC Guide sagt, dass Committer Code aktualisieren dürfen, während nur das PMC als Gremium über formelle Software-Releases abstimmen darf. Das wertet Beiträge nicht ab. Es trennt die technische Fähigkeit, Quellen zu ändern, von dem institutionellen Akt, ein Artefakt unter dem offiziellen Namen Apache zu veröffentlichen.

Ein Release braucht darum ein festes Objekt: Kandidat, Source-Revision, Signatur, Prüfsumme oder endgültige Kennung. Eine Stimmenzahl ohne Objekt sagt nicht, worüber entschieden wurde. Umgekehrt beweist ein PMC-Release-Votum nicht, dass das Board jede Zeile geprüft hat, alle Beitragenden zustimmten oder Nutzer das Paket übernehmen werden.

Das Code-Veto ist stark, aber kein allgemeines Stoppsignal

Der Apache Voting Process unterscheidet Verfahrensfragen, Codeänderungen und Paket-Releases. Für eine nicht-lazy Codeänderung verlangt er drei +1 und kein -1. Ein -1 eines qualifizierten Wählers kann ein Veto sein, braucht eine technische Begründung und kann nicht überstimmt werden, bis der Wähler es zurückzieht.

Gerade die begrenzte Reichweite macht die Regel stark. Nicht jeder negative Kommentar in irgendeiner Liste stoppt alle Apache-Aktivität. Erforderlich sind die konkrete Änderung, die anwendbare Gruppe und die Qualifikation. Der Nachweis sollte Vorschlag und Version, technischen Grund, Status des Wählers, Diskussion und Ausgang—Rücknahme, Änderung oder Aufgabe—bewahren. Daraus wird nicht automatisch Körperschaftspolitik, Markturteil oder Fehlervorwurf.

Das formelle Release folgt einem anderen Test

Für ein Paket-Release nennt Apache mindestens drei bindende +1 und mehr bindende positive als negative Stimmen; die Anleitung sagt, Releases können nicht vetoed werden. Das ist keine abgeschwächte Code-Regel, sondern eine andere Regel für eine andere Handlung.

Deshalb kann ein -1 nicht ohne Aktionsart und Regel als „Release-Veto“ bezeichnet werden. Es kann ein Veto zu einer Codeänderung, eine beratende Stimme oder ein früher Einwand sein. Ein bestandenes Release beseitigt technische Einwände nicht und beweist weder Sicherheit, Adoption noch Marktreife. Es belegt nur den formellen Status dieses Artefakts nach der Release-Regel.

Das PMC führt das Projekt; das Board hält den Körperschaftsrahmen

PMCs tragen technische und gemeinschaftliche Richtung, Releases und Projektaufsicht. Das Board schafft PMCs, ernennt Vice Presidents/Chairs, verwaltet Vermögen und Gesamtpolitik, erhält Berichte und kann bei einem dysfunktionalen oder regelwidrigen PMC handeln. Zugleich erklärt ASF, dass das Board keine technische Richtung für Projekte vorgibt.

Directors erhalten nicht automatisch Committership, PMC-Mitgliedschaft oder bindende technische Stimmen. Wer technisch Einfluss nehmen will, muss im jeweiligen Projekt Merit erwerben. Members wählen Directors, doch Membership allein gibt keine technische Leitungsmacht in Projekten ohne projektspezifischen Merit.

Der Chair verbindet die Ebenen, ohne sie zu verschmelzen. Im PMC hat er eine gewöhnliche Stimme; als Officer verantwortet er Bericht und offizielles Roster. Eine interne PMC-Entscheidung über einen Chair-Wechsel braucht weiterhin eine Board Resolution, um zur formellen Ernennung zu werden.

Einen Release-Befugnisnachweis veröffentlichen

Für eine Codeänderung sollte der Nachweis Änderung, Prüfweg, Regel, qualifizierte Wähler, ausdrückliche Positionen, technische Grundlage eines gültigen Vetos und Ergebnis ausweisen. Für ein Release sollte er Artefakt, PMC, Zeitfenster, bindende Abstimmungsregel, Ergebnis und Endkennung verbinden. Für einen Körperschaftsvorgang muss getrennt stehen, ob es sich um Resolution, Ernennung, Anfrage oder Berichtsprüfung handelt.

Dies ist keine neue Apache-Pflicht. Es ist Daniel Kades editorische Empfehlung, damit „Veto“, „Release“, „PMC“ und „Board“ nicht mehr Befugnis behaupten, als der betreffende Vorgang beweist.

Sources

  1. Apache Corporate Governance — PMCs
  2. Apache Voting Process
  3. Apache Project Management Committee Guide
  4. Apache Corporate Governance — Board of Directors
  5. Apache Corporate Governance — Members
  6. Lu Heng, The Multi-Stakeholder Mirage