Herausforderung: Es gibt keinen anderen Guido

Es gibt keine andere Einzelperson mit der einzigartigen Fähigkeiten von Guido van Rossum. Eine solche Person müsste über die technische, kommunikative und organisatorische Erfahrung verfügen, um das Projekt erfolgreich zu leiten. Insbesondere müsste die Person in der Lage sein,

• eine kohärente langfristige Vision für das Projekt festzulegen und zu artikulieren;
• ein tiefes technisches Verständnis der Laufzeitumgebung, der Standardbibliothek und des breiteren Drittanbieter-Bibliothekskontextes zu besitzen;
• umstrittene Probleme auf eine für alle Beteiligten akzeptable Weise zu verhandeln und zu lösen;
• freie Zeit und die Energie zu haben, um kontinuierliches Engagement über Jahre hinweg aufrechtzuerhalten.

Risiko: Böswilliger Diktator auf Lebenszeit

Was wäre, wenn wir jemanden bekämen, der für die Position nicht so gut geeignet ist wie unser erster Diktator? Es gibt mögliche Szenarien, in denen dies zu schwerwiegenden Folgen führen könnte.

Der Diktator könnte aufgrund mangelnder technischer Tiefe, einer „knappen“ Wahl, inkonsistenter Vision, schlechter Fähigkeit, mit Konflikten umzugehen, oder Burnouts nicht genügend Vertrauen aufbauen. Angesichts einer kontroversen Entscheidung, die vom Diktator auf eine bestimmte Weise getroffen wurde, kann ein Diktator mit unzureichendem Vertrauen zu einer Spaltung innerhalb des Projekts führen.

Die Diktator-Einrichtung lädt zu Lobbyismus ein, der sich auf eine einzelne Person konzentriert. Es sei denn, diese Person ist aufgrund von Reichtum, Gesundheit und einer stabilen Lebenssituation immun gegen Einflussnahme, birgt dies das Risiko, dass böswillige Akteure das Projekt hinter den Kulissen steuern.

Schließlich kann der Diktator, der aus einem bestimmten Teil der Community stammt, den Bedürfnissen und Interessen dieses bestimmten Teils der Benutzerbasis mehr Gewicht verleihen und andere entfremden.

Beobachtung: Wir brauchen eigentlich keinen Diktator

Die Ironie des Diktator-Modells ist, dass es eine Wahl erfordert. Besser noch, wir brauchen eine Wahl, um überhaupt über das zu entscheidende Governance-Modell zu bestimmen.

Wenn wir bereits zwei Probleme dieser Tragweite durch den Community-Prozess lösen können, warum sollten wir ihn nicht für alle nachfolgenden Entscheidungen weiter nutzen?

Risiko: Das warme und kuschelige Gefühl eines vagen Vorschlags

Eine letzte erwähnenswerte Sache ist, dass, wenn ein BDFL-Modell vorgeschlagen wird, es einfach ist, die oben genannten Kritikpunkte zu umgehen, indem man nicht erwähnt, *wer* der BDFL sein soll. Auf diese Weise kann der hoffnungsvolle Leser seine besten Erwartungen und Wünsche auf den abstrakten BDFL projizieren und die Idee attraktiver erscheinen lassen. Das ist ein Fehler.

Ohne Nennung des BDFL im Modellvorschlag sprechen wir nicht über ein konkretes Modell. Wir können die harten Fragen vermeiden, indem wir sie nicht stellen und beantworten. Wir können uns unser Best-Case-Szenario vorstellen, einen Kandidaten, den wir uns wünschen, um die Rolle zu bekleiden.

Das Auslassen eines Namens für den BDFL stellt das Community-Modell auch in einen unfairen Nachteil. Wir kennen bereits das Gute, das Schlechte und das Hässliche unserer Core-Entwicklergruppe. Es ist kein platonisches Ideal, keine perfekte Kugel ohne Reibung. Tatsächlich erwarten wir, dass es einiges an Reibung und Unvollkommenheiten gibt.

Daher, um den BDFL-Modellvorschlag fair zu bewerten, stellen Sie sich, werter Leser, die schlechteste Person in unserem Team als diesen BDFL vor. Eine konkrete menschliche Person. Stellen Sie sich vor, es bin ich.

Fazit Auch wenn dies unsere Geschichte war, dient dieses Modell ohne Guido nicht den besten Interessen der Sprache für die Zukunft.

Risiko: Verwässerung und Verwirrung

Dieses Modell begünstigt eine kleine Gruppe von drei bis fünf Personen. Auf diese Weise teilt es die meisten Kritikpunkte mit dem Diktator-Modell, nur verstärkt. Wenn nicht eine, sondern beispielsweise drei Personen Macht innehaben, verwässert dies die Verantwortung und bietet dennoch ein hohes Risiko für Lobbyismus, unzureichendes Vertrauen oder die Entfremdung von Teilen der Community.

Risiko: Interne Konflikte

Darüber hinaus schafft die gemeinsame Verantwortung für die Governance durch mehrere Personen reichlich Gelegenheit für interne Konflikte, eine inkonsistente langfristige Vision des Projekts und vervielfacht den erforderlichen kontinuierlichen Zeitaufwand der Mitglieder (es ist kein Quorum, wenn sie aufgrund anderer Zeitverpflichtungen kein „Quorum erreichen“ können).

Genau wie bei einem reibungslosen sphärischen BDFL lehnen Sie Ideen für Räte ab, ohne darüber nachzudenken, wie es für Sie wäre, wenn dieser Rat aus drei Personen bestünde, die Sie für die Rolle als ungeeignet erachten. Stellen Sie sich vor, ich hätte zwei Freunde.

Am wichtigsten ist, dass wir, genau wie bei einem Diktator, keinen Rat brauchen. Bis wir einen hätten, hätten wir bereits zwei erfolgreiche Wahlen hinter uns. Warum nicht weiter abstimmen?

Fazit Dieses Modell birgt ähnliche Risiken wie ein Diktator, nur schlimmer.

Das Kernteam

Das Python-Projekt wird von einem Team von Core-Entwicklern entwickelt. Während die Mitgliedschaft durch die Präsenz im „Python Core“-Team in der Organisation „python“ auf GitHub bestimmt wird, nimmt die Mitwirkung viele Formen an

• Änderungen in das Repository einchecken;
• Pull-Anfragen von anderen überprüfen;
• Fehlerberichte im Issue-Tracker triagieren;
• Themen auf offiziellen Python-Kommunikationskanälen diskutieren.

Einige Mitwirkende können als ruhend betrachtet werden, das heißt, sie haben in den letzten beiden Releases von CPython nicht mitgewirkt. Jeder ruhende Mitwirkende kann jederzeit die Mitwirkung wieder aufnehmen.

Experten

Das Python Developer’s Guide listet eine Reihe von Interessensgebieten zusammen mit den Namen von Core-Entwicklern auf, die in dem jeweiligen Bereich als Experten anerkannt sind. Ein Experte oder ein Unterteam von Experten hat folgende Verantwortlichkeiten

• zeitnahe Beantwortung von Issues im Bug-Tracker, die dem jeweiligen Interessengebiet zugeordnet sind;
• zeitnahe Überprüfung von Pull-Anfragen, die dem jeweiligen Interessengebiet zugeordnet sind;
• Überblick über kohärentes Design bei der Weiterentwicklung des jeweiligen Interessengebiets.

Ein Core-Entwickler kann sich nach Belieben für ein Interessengebiet zuweisen und von ihm abweisen. Bestehende Experten, die für das jeweilige Interessengebiet aufgeführt sind, müssen über diese Änderung informiert werden und einstimmig zustimmen.

Wenn ein Interessengebiet mehrere Experten auflistet, bilden diese ein Unterteam innerhalb des Core-Teams. Sie sind gemeinsam für das jeweilige Interessengebiet verantwortlich.

Ein Core-Entwickler sollte vermeiden, gleichzeitig Experte in zu vielen Interessengebieten zu sein. Dieses Dokument spezifiziert absichtlich keine Höchstzahl, es signalisiert lediglich, dass Überlastung zu Burnout führt und ein Risiko für die Funktionsfähigkeit des Projekts ohne einen bestimmten Mitwirkenden darstellt.

Moderatoren

Es gibt eine Gruppe von Personen, von denen einige keine Core-Entwickler sind, die dafür verantwortlich sind, dass die Diskussionen auf offiziellen Kommunikationskanälen dem Verhaltenskodex entsprechen. Sie ergreifen Maßnahmen bei Verstößen.

PEP, Erweitert

Der PEP-Prozess wird durch die folgenden Änderungen und Klarstellungen zu den bereits in PEP 1 enthaltenen Informationen erweitert

• PEPs werden nicht gemergt, bis die endgültige Entscheidung darüber getroffen ist; bis dahin sind sie offene Pull-Anfragen auf GitHub;
  • um die Überprüfung zu erleichtern, sollten alle Änderungen an der zu überprüfenden PEP als separate Commits vorgenommen werden, die einen granularen Vergleich ermöglichen;
• eine eingereichte PEP muss das Interessengebiet und die zuständigen Experten als die Instanz identifizieren, die die endgültige Entscheidung darüber trifft;
• Wenn der PEP-Autor einer der Experten des relevanten Interessengebiets ist, muss er eine andere Person außerhalb dieses Interessengebiets benennen, die an der endgültigen Entscheidung an seiner Stelle mitwirkt;
• der PEP-Autor ist dafür verantwortlich, Feedback zur PEP über die offiziellen Kommunikationskanäle zu sammeln und zu integrieren, mit dem Ziel, Konsens aufzubauen;
• alle Community-Mitglieder müssen in die Lage versetzt werden, Feedback zu geben;
• irgendwann postet einer der genannten Experten einen „Zusammenfassenden Kommentar“, der den aktuellen Stand der Diskussion darlegt, insbesondere die wichtigsten Streitpunkte und Kompromisse; gleichzeitig schlägt der Experte eine „Motion for Final Comment Period“ (FCP) vor, zusammen mit einem vorgeschlagenen Beschluss zur
  • Annahme;
  • vorläufige Annahme;
  • Ablehnung; oder
  • Vertagung der PEP.
• um in die FCP einzutreten, muss die PEP von allen Experten des relevanten Interessengebiets unterzeichnet werden;
• die FCP dauert vierzehn Kalendertage, damit die Stakeholder letzte Einwände einreichen können, bevor eine Entscheidung getroffen wird.

Sehr kontroverse PEPs

Wenn ein Kernmitwirkender sich stark gegen eine bestimmte PEP ausspricht, kann er während ihrer FCP einen Antrag auf Ablehnung per Abstimmung stellen. Die Abstimmungsdetails sind unten unter „Abstimmungsmechanismen“ beschrieben.

Dies sollte ein letztes Mittel sein und daher eine seltene Angelegenheit. Es spaltet das Kernteam und ist ein stressiges Ereignis für alle Beteiligten. Die für eine FCP für eine PEP zuständigen Experten sollten jedoch ein gutes Gespür dafür haben, ob ein Antrag auf Ablehnung per Abstimmung wahrscheinlich ist. In einem solchen Fall sollte darauf geachtet werden, eine vorzeitige Einreichung einer FCP zu vermeiden.

Es gibt keine Möglichkeit für die umgekehrte Situation, d. h. wenn die Experten eine PEP ablehnen wollen, andere sie aber akzeptiert haben möchten. Dies stellt sicher, dass die zuständigen Experten das letzte Wort über das haben, was einfließt. Wenn Sie diese Änderung wirklich wollen, finden Sie einen Weg, sie zu überzeugen.

Moderatoren auf offiziellen Kommunikationskanälen setzen in erster Linie den Verhaltenskodex durch, um eine gesunde Interaktion zwischen allen Interessengruppen zu gewährleisten. Die Durchsetzung kann dazu führen, dass ein bestimmter Teilnehmer von weiteren Diskussionen und damit vom Entscheidungsprozess ausgeschlossen wird.

Wiederholung von aufgeschobenen und abgelehnten PEPs

Wenn eine PEP vertagt oder abgelehnt wird, sollten die zuständigen Experten zuerst kontaktiert werden, bevor ein weiterer Versuch mit derselben Idee unternommen wird. Wenn die Experten zustimmen, dass es substantielle Beweise gibt, die eine erneute Prüfung der Idee rechtfertigen, kann eine Pull-Anfrage zur Bearbeitung der vertagten oder abgelehnten PEP geöffnet werden.

Das Versäumnis, im Voraus eine ordnungsgemäße Zustimmung der Experten einzuholen, führt wahrscheinlich zur sofortigen Ablehnung einer Pull-Anfrage für eine vertagte oder abgelehnte PEP.

Nominierung eines neuen Core-Entwicklers

Ein Pate nominiert eine Person zum neuen Core-Entwickler, indem er dies auf offiziellen Kommunikationskanälen veröffentlicht. Eine Abstimmung wird eröffnet.

Wenn ein bestehender Core-Entwickler mit der Ernennung des Nominierten zum Commit-Bit nicht einverstanden ist, sollte er diesen Bedenken vorzugsweise im Nominierungsthread ansprechen. Wenn keine zufriedenstellende Lösung gefunden wird, kann er eine negative Stimme abgeben.

In der Praxis sollte die Nominierung einer Person zum Core-Entwickler oft auf Überraschung bei anderen stoßen, dass diese Person noch kein Core-Entwickler ist. Mit anderen Worten, sie sollte erfolgen, wenn der Kandidat bereits bekannt und von anderen gut genug vertraut ist. Wir sollten Nominierungen basierend auf *Potenzial* vermeiden.

Misstrauensvoten

• Entfernen eines Core-Entwicklers aus dem Kernteam;
• Auflösung des Expertenteams für ein bestimmtes Interessengebiet.

Diese beschreiben eine Situation, in der ein Core-Entwickler gewaltsam aus dem Kernteam entfernt wird oder ein Expertenteam gewaltsam aufgelöst wird. Hoffentlich müssen diese nie angewendet werden, aber sie werden explizit erwähnt, um zu zeigen, wie ein dysfunktionaler Interessensbereich geheilt werden kann.

Wenn ein Core-Entwickler per Abstimmung aus dem Kernteam entfernt wird, verliert er die Fähigkeit, mit dem Projekt zu interagieren. Es liegt im Ermessen der Moderatoren, ob seine Fähigkeit, im Bug-Tracker und auf GitHub zu posten, entzogen wird oder ob sein zukünftiges Verhalten von Fall zu Fall moderiert wird.

Wenn das Expertenteam für ein Interessengebiet aufgelöst wird, können andere Core-Entwickler nach Belieben einspringen, um die Lücke zu füllen. Mitglieder des aufgelösten Expertenteams können sich nicht selbst zur Rückkehr nominieren.