Zusammenfassung

  • Die CPC-Satzung führt ab dem Wahlzyklus Herbst 2026 die bisherigen nicht-Impact-Projekt- und Regular-Member-Vertretungen in höchstens fünf Community Voting Member-Sitzen zusammen.
  • Beobachtung, Regular-Member-Status, Zugehörigkeit zum Wahlvolk und ein Stimmrechtssitz sind verschiedene Tatsachen. Community Voting Members müssen Regular Members sein und dürfen nicht zugleich als Voting Member eines Impact-Projekts dienen.
  • Ein Übergangsnachweis sollte alten Sitz, neue Klasse, Eignung, Wahlnenner, Ergebnis, Arbeitgebergrenze sowie Board-, CPC- und Projektzuständigkeit getrennt festhalten. Er darf weder einen Plan als fertige Wahl noch interne Teilnahme als allgemeines Mandat ausgeben.

Eine angekündigte Regel ist noch keine besetzte Körperschaft

In einer Open-Source-Stiftung kann die öffentliche Norm der tatsächlichen Wirkung vorausgehen. Eine neue Bezeichnung steht in der Satzung, eine Sitzung ist für Beobachter offen, ein Repository kündigt eine künftige Klasse an. Das sind nützliche Belege. Sie belegen nicht, dass Nominierungen eröffnet, Wahlberechtigte geprüft, Stimmen gezählt oder bestimmte Personen eingesetzt wurden.

Die OpenJS-Satzung zieht diese institutionellen Linien klar. Der Cross Project Council, CPC, ist die technische Führung der Foundation; das Board ist ihre geschäftliche Führung. Das Board setzt die Gesamtpolitik für den CPC, der innerhalb dieses Rahmens technische, delegierte Verantwortung trägt. Für Herbst 2026 beschreibt die Satzung den Wechsel von zwei getrennten nicht-Impact-Stimmwegen zu Community Voting Members.

Damit ist die geplante Architektur nachgewiesen, nicht das Ergebnis. Die überprüften öffentlichen Quellen sagen nicht, dass eine Kandidaturperiode begonnen hat, wie viele Sitze tatsächlich besetzt wurden, wer gewählt wurde oder zu welchem Datum ein Ergebnis wirksam wurde. Wer die Zukunftsregel als gegenwärtige Besetzung schreibt, ersetzt eine Quellenlage durch Erwartung.

Nach dem Übergang müssen Beteiligte die Lage ohne Insider-Erzählung nachvollziehen können. Hat eine frühere Vertretung ihr Mandat beendet, ist sie zurückgetreten, ersetzt worden, nur Regular Member geworden oder für die neue Klasse angetreten? Wie viele der maximal fünf Sitze wurden besetzt? Wie viele Impact Project Voting Members und Regular Members waren am maßgeblichen Tag wahlberechtigt? Gegen welche Gesamtzahl wurde die Satzungsgrenze von einem Viertel derselben Arbeitgeberzugehörigkeit geprüft? Lag die relevante Entscheidung beim Board, beim CPC oder bei einem selbstverwalteten Projekt?

Das sind keine Vorwürfe. Es sind die Angaben, die verhindern, dass eine spätere Namensliste als nicht erklärte Übertragung von Entscheidungsbefugnis gelesen wird.

Vier verschiedene Bedeutungen von „Community“

Die Satzung unterscheidet Observers, Regular Members und Voting Members. Das CPC-Repository erlaubt Nichtmitgliedern die Teilnahme als Beobachter. Die Governance-Regeln beschreiben, wie ein Active OpenJS Collaborator mit aktueller und kontinuierlicher Mitarbeit Regular Member werden kann. Für die Community-Voting-Member-Wahl ist der Kreis enger: Impact Project Voting Members und Regular Members bilden das Wahlvolk.

Ein Observer kann die öffentliche Arbeit verfolgen und am Konsensprozess teilnehmen. Diese Beteiligung ist real, schafft aber weder einen Eintrag im Wahlregister noch einen Stimmrechtssitz.

Ein Regular Member hat einen präziseren institutionellen Status. Verlangt werden aktuelle, anhaltende Beiträge zu Projekt, Community, Collaboration Space oder CPC-Arbeit sowie ein Prüfverfahren. Der Status ist Voraussetzung für die Kandidatur und Teil des Wahlvolks, aber kein Wahlnachweis.

Ein Impact Project Voting Member erhält seinen Sitz aus einer anderen Quelle. Jedes Impact-Projekt darf nach eigenem Verfahren bis zu zwei Personen benennen. Diese Klasse bleibt im neuen Aufbau erhalten. Dass ihre Mitglieder beim Community-Vote mitwirken, macht ihre eigenen Sitze nicht zu Community-Sitzen.

Ein Community Voting Member ist die neu definierte Stimmklasse mit höchstens fünf Sitzen. Kandidierende müssen Regular Members sein und dürfen nicht gleichzeitig Impact-Projekt-Stimmvertreter sein. Der Satz „die Community hat gewählt“ kann deshalb vier Fragen verschleiern: Wer war anwesend, wer war Regular Member, wer konnte wählen und wer erhielt tatsächlich einen Sitz? Die Satzung definiert die Kategorien; die Wahlakte muss die letzten Tatsachen belegen.

Hier gilt Heng Lus Unterscheidung: Teilhabe kann Fachwissen, Warnung und Einspruch liefern. Sie schafft nicht allein ein Principal-Mandat über alle Betroffenen. Eine offene CPC-Sitzung und eine interne Wahl sind Belege für einen abgegrenzten Foundation-Prozess, nicht für einen allgemeinen Vertretungsanspruch über das JavaScript-Ökosystem.

Der neue Sitz ersetzt keine andere Zuständigkeit

Der Klassenwechsel ordnet nicht sämtliche Macht um den CPC neu. Voting Members tragen die finalen CPC-Aufgaben, die ihnen die Satzung zuweist. Der CPC sucht lazy consensus und verwendet einen geregelten Abstimmungsweg, wenn Einwände nicht aufgelöst werden können. Das Board behält Gesamtpolitik, insbesondere rechtliche Befugnisse, und seine Rolle bei Satzungsänderungen. Projekte bleiben mit ihren dokumentierten technischen Prozessen selbstverwaltet.

Die Ebenen stehen in Verbindung, werden aber nicht identisch. Ein CPC Director kann Projekte und zugehörige Communities beim Board vertreten. Eine Projektcharta kann CPC-Zustimmung benötigen. Ein technisches Thema kann an das Board eskaliert werden. Daraus wird ein Community Voting Member weder automatisch Board Director noch Sprecher aller Maintainer oder innerer Entscheider eines Projekts. Der Nachweis muss die tatsächlich geltende Rolle nennen.

Das bestehende Verfahren hinterlässt bereits Spuren: ein öffentliches Issue zum Beginn der Nominierung, einen README-Update-Pull-Request nach der Wahl, eine private Ergebnisnotiz sowie Agenden und Sitzungsunterlagen. Es gibt zugleich berechtigte nichtöffentliche Grenzen bei Personen-, Rechts- und bestimmten Board-Themen. Transparenz bedeutet nicht, jede private Akte offenzulegen. Sie bedeutet, entscheidende öffentliche Tatsachen verbinden zu können.

Ein neuer README-Name enthält für sich weder Mandatsende, Wahlnenner noch Laufzeit. Die Governance-Regel sagt, dass frühere Voting Members nach ihrem Mandatsende grundsätzlich Regular Members werden, wenn sie nichts anderes erklären. Das ist ein sinnvoller Standardstatus, aber kein individueller Austrittsnachweis. „Bis zu fünf“ beweist nicht, wie viele Sitze besetzt wurden. Auch die Arbeitgebergrenze von einem Viertel ist ohne datierten Gesamtbestand und Zuordnungsgrundlage nicht nachrechenbar.

Der Übergangsnachweis für Community Voting Members

Daniel Kade schlägt einen kompakten Community-Voting-Member-Übergangsnachweis vor. Er ändert die Satzung nicht und verlangt keine Offenlegung privater Kandidatenunterlagen. Er verbindet Fakten, die sonst über Issues, Agenden, Listen und Repository-Änderungen verteilt bleiben.

Erstens braucht es den Zyklusstatus: geplanter Übergang, Nominierungen offen, Wahl läuft, Ergebnis bestätigt oder Korrektur. Er verweist auf den maßgeblichen Satzungstext, nennt alte und neue Klasse und verhindert, dass eine Zukunftsregel wie eine vollzogene Ernennung wirkt.

Zweitens folgt eine Sitzkarte. Für jeden betroffenen alten Weg nennt sie Sitzquelle, öffentlich bekannten Inhaber, reguläres Mandatsende und Ausgang: beendet, Rücktritt, Ersatz, nur Regular Member, Kandidatur für die neue Klasse oder nicht öffentlich angegeben. Für die neuen Sitze trennt sie besetzt, frei und nicht öffentlich bestimmt. Fehlender Name ist kein automatischer Leerstandsbeweis.

Drittens dokumentiert der Block Eignung und Wahlvolk die Kandidaturbedingung und die beiden Satzungskategorien, ergänzt durch eine datierte Gesamtzahl oder eine aufbewahrte Prüfmethode. Private Einzelbegründungen müssen nicht veröffentlicht werden; der Nenner eines Ergebnisses muss verständlich bleiben.

Viertens verbindet er Verfahren und Ergebnis: Nominierungsissue, tatsächlich verwendete Methode, soweit öffentlich, Ergebnisnotiz, README-Pull-Request, Wirksamkeitsdatum und daraus folgende Voting-Member-Liste. Die Satzung nennt Condorcet und Single Transferable Vote als mögliche Verfahren. Daraus darf nicht auf das Verfahren eines konkreten Zyklus geschlossen werden.

Fünftens enthält er eine Zusammensetzungsprüfung: Gesamtzahl der Voting Members zum Wirksamkeitsdatum, öffentliche Arbeitgebergrundlage soweit verfügbar, Viertelgrenze und Status — erfüllt, korrigiert, offen oder nicht veröffentlicht. Eine Satzungsprüfung ist kein Konfliktvorwurf.

Zum Schluss stehen Zuständigkeitsgrenze und Korrekturlog. Board, CPC, CPC Directors und Projektautonomie werden getrennt verlinkt. Außerdem wird ausgesprochen, was die Öffentlichkeit nicht belegt: privater Eignungsgrund, unveröffentlichte Stimmenzahl, späterer Rücktritt oder Board-Entscheid. Korrekturen werden so datierte Ergänzungen statt stiller Überschreibungen einer Liste.

Offene Governance bedeutet nicht, dass jede teilnehmende Person alle Befugnisse hat. Sie bedeutet, dass jede tatsächliche Befugnis eine sichtbare Quelle, Reichweite und Endlage hat. Der Herbstübergang gibt OpenJS die Chance, diese Unterscheidung dann festzuhalten, wenn sie entsteht.

Quellen

  1. OpenJS Cross Project Council Charter
  2. OpenJS Cross Project Council Governance
  3. OpenJS Cross Project Council repository and current roster
  4. OpenJS Foundation Governance archive
  5. Lu Heng — The Multi-Stakeholder Mirage