Zusammenfassung

Diese PEP schlägt eine Fortsetzung des Modells des einzelnen technischen Projektleiters vor, euphemistisch als Wohltätiger lebenslanger Diktator (BDFL) bezeichnet, für die Python-Governance, die in dieser PEP fortan Gracious Umpire Influencing Decisions Officer (GUIDO) genannt wird. Diese Namensänderung spiegelt sowohl die erweiterte Sicht des GUIDO als endgültiger Schlichter für den Entscheidungsprozess der Python-Sprache in Absprache mit der breiteren Entwicklungsgemeinschaft wider, als auch die Erkenntnis, dass „lebenslang“, obwohl vielleicht aspirativ, nicht unbedingt im besten Interesse des Wohlergehens der Sprache oder des GUIDO selbst ist.

Diese PEP beschreibt

• Die Begründung für die Beibehaltung des Modells des einzelnen technischen Leiters
• Der Prozess, wie der GUIDO ausgewählt, gewählt, gehalten, abgesetzt und nachfolgt wird;
• Die Rollen des GUIDO im Entwicklungsprozess der Python-Sprache;
• Die Länge der Amtszeit;
• Die Beziehung des GUIDO zu einem Rat der Pythonistas (CoP), der den GUIDO in technischen Fragen berät;
• Die Größe, Wahl und Rollen des CoP;
• Der Prozess der Delegierung von Entscheidungen;
• Jegliche Änderungen am PEP-Prozess, um sie an das neue Governance-Modell anzupassen;

Diese PEP ernennt keinen neuen BDFL. Sollte dieses Modell übernommen werden, wird es in PEP 13 zusammen mit den Namen aller in dieser PEP beschriebenen Amtsträger kodifiziert.

Ablehnung der PEP

PEP 8010 wurde durch eine Abstimmung der Kernentwickler abgelehnt, wie in PEP 8001 am Montag, dem 17. Dezember 2018, beschrieben.

PEP 8016 und das von ihr beschriebene Governance-Modell wurden stattdessen gewählt.

Offene Diskussionspunkte

Verschiedene Anpassungen der Parameter dieser PEP sind während des Governance-Diskussionsprozesses zulässig, wie z. B. die genaue Größe des CoP, die Amtsdauer und die Abstimmungsverfahren. Diese werden zum Zeitpunkt der Abstimmungsbereitschaft der PEP kodifiziert.

Die in dieser PEP beschriebenen Abstimmungsverfahren und -ereignisse werden standardmäßig auf die in PEP 8001 festgelegte Abstimmungsmethode angewendet, obwohl dies, da diese PEP zum Zeitpunkt der Erstellung noch diskutiert wird, Änderungen unterliegt.

Es ist erlaubt und vielleicht sogar erwünscht, dass diese Parameter im Laufe der Zeit mit zunehmender Erfahrung mit diesem Modell bei der Benennung zukünftiger GUIDOs angepasst werden, um einen reibungsloseren Regierungsprozess zu ermöglichen.

Warum ein einzelner technischer Leiter?

Warum dieses Modell und nicht irgendein anderes? Es läuft auf die „Vision“ hinaus. Design by Committee hat viele bekannte Nachteile, die zu einer Sprache führen, die neue Features basierend auf den unterschiedlichen Interessen der Mitwirkenden zu dieser Zeit ansammelt. Ein berühmtes Sprichwort lautet: „Ein Kamel ist ein Pferd, das vom Komitee entworfen wurde.“ Kann eine Sprache, die vom Komitee entworfen wurde, „zusammenhängen“? Fühlt sie sich wie eine kohärente, in sich geschlossene Sprache an, bei der die Regeln Sinn ergeben und leicht zu merken sind?

Ein einzelner technischer Leiter kann diese Vision besser fördern als ein Komitee, sei es ein kleines (z. B. 3 oder 5 Personen) oder die gesamte Python-Gemeinschaft. Jeder Teilnehmer hat seine eigene Vision von dem, was „Python“ ist, und dies kann zu Unentschlossenheit oder unlogischen Entscheidungen führen, wenn diese individuellen Visionen im Konflikt stehen. Sollte CPython 3x schneller sein oder sollen wir die C-API erhalten? Das ist eine sehr schwierige Frage, um einen Konsens zu erzielen, da keine der beiden Entscheidungen richtig oder falsch ist. Aber schlimmer als die falsche Entscheidung zu treffen, könnte es sein, den Status quo zu akzeptieren, weil kein Konsens gefunden werden konnte.

Flexibilität

Flexibilitätsgrade werden sowohl dem GUIDO als auch dem CoP durch Unter spezifikation gewährt. Diese PEP beschreibt, wie Konflikte gelöst werden, erwartet aber von allen Beteiligten, einschließlich Kernentwicklern, Community-Mitgliedern und Amtsträgern, stets das Wohl von Python und seinen Benutzern im Auge zu haben. Die PEP geht davon aus, dass gegenseitiger Respekt und beste Absichten immer zu einem Konsens führen und dass der Verhaltenskodex alle Interaktionen und Diskussionen regelt.

Die Rolle des GUIDO

Eine der wichtigsten Aufgaben des GUIDO ist es, eine übergreifende, breite und kohärente Vision für die Entwicklung der Python-Sprache über mehrere Veröffentlichungen hinweg zu bieten. Dies ist besonders wichtig, wenn Entscheidungen dauerhafte Auswirkungen und konkurrierende Vorteile haben. Wenn beispielsweise rückwärts inkompatible Änderungen an der C-API zu einer Verdoppelung der Python-Leistung führen, werden verschiedene Community-Mitglieder wahrscheinlich überzeugend für beide Seiten der Debatte eintreten, und ein klarer Konsens ergibt sich möglicherweise nicht. Jede Wahl ist gleichermaßen gültig. In Absprache mit dem CoP wird die Vision des GUIDO die endgültige Entscheidung leiten.

Der GUIDO ist die oberste Autorität für Entscheidungen über PEPs und andere Angelegenheiten, einschließlich der Frage, ob eine bestimmte Änderung PEP-würdig ist. Wie heute sind viele – ja vielleicht die meisten – Entscheidungen durch Diskussion und Lösung im Issue Tracker, Merge-Anfragen und Diskussionsforen zu treffen, in der Regel mit Input oder Führung von Experten auf dem jeweiligen Gebiet. Wo dieses Arbeitsverfahren einwandfrei funktioniert, kann es unverändert fortgeführt werden. Dies hilft auch, die Arbeitsbelastung für CoP und GUIDO zu reduzieren, sodass nur die wichtigsten Entscheidungen und die breitere Landschaftsübersicht an die zentrale Autorität überlassen bleiben.

Ebenso kann der GUIDO, wenn eine bestimmte Änderung eine PEP erfordert, aber der GUIDO in Absprache mit dem CoP Experten identifiziert, die die volle Zuversicht haben, die endgültige Entscheidung zu treffen, einen Delegierten für die PEP ernennen. Während der GUIDO die oberste Autorität bleibt, wird erwartet, dass der GUIDO die Autorität des Delegierten als endgültigen Schlichter der PEP nicht untergräbt und in der Tat unterstützt.

Der GUIDO hat die volle Befugnis, unproduktive Diskussionen, Ideen und Vorschläge zu beenden, wenn klar ist, dass der Vorschlag gegen die langfristige Vision für Python verstößt. Dies geschieht mit Mitgefühl für die Befürworter der Änderung, aber mit Rücksicht auf die Gesundheit und das Wohlergehen aller Community-Mitglieder. Eine toxische Diskussion über einen Sackgassen-Vorschlag nützt niemandem etwas und kann per Dekret beendet werden.

Zusammenfassend lässt sich sagen: Der GUIDO hat die Befugnis, eine endgültige Aussage zu jedem Thema, technisch oder nicht-technisch, zu treffen, mit Ausnahme der Änderung der Governance-PEP selbst.

Autorität kommt von der Gemeinschaft

Die Autorität des GUIDO liegt letztendlich bei der Gemeinschaft. Ein abtrünniger GUIDO, der das Vertrauen der Mehrheit der Gemeinschaft verliert, kann abgesetzt und eine neue Wahl durchgeführt werden. Dies ist ein äußerst seltenes und unwahrscheinliches Ereignis. Dies ist eine ausreichende Notfallmaßnahme für den schlimmsten Fall, daher sollte sie nicht leichtfertig unternommen werden. Der GUIDO sollte nicht befürchten, wegen einer Entscheidung abgesetzt zu werden, auch wenn diese Entscheidung nicht von der Mehrheit der Python-Entwickler bevorzugt wird. Eine Absetzung sollte für Handlungen reserviert sein, die der Python-Sprache oder der Gemeinschaft schwere Nachteile bringen.

Der Rat der Pythonistas (siehe unten) hat die Verantwortung, eine Misstrauensabstimmung einzuleiten.

Amtszeit und Amtszeitbegrenzungen

Der GUIDO wird für drei Python-Releases dienen, etwa 4,5 Jahre bei der aktuellen Release-Kadenz. Wenn sich die Release-Kadenz von Python ändert, sollte sich die Länge der Amtszeit des GUIDO auf 4,5 Jahre runden. Wie die Rundung erfolgt, bleibt der potenziellen Release-Kadenz-PEP überlassen. Nach dieser Zeit wird eine neue Wahl gemäß den unten dargelegten Verfahren durchgeführt. Es gibt keine Amtszeitbegrenzungen, sodass der GUIDO so lange wiedergewählt werden kann, wie er möchte.

Wir erwarten, dass GUIDOs ihre gesamte Amtszeit erfüllen, aber natürlich kann das Leben dazwischenkommen. Sollte der GUIDO sein Amt vorzeitig niederlegen müssen, wird die vakante Stelle durch das unten beschriebene Verfahren zur Auswahl eines neuen GUIDO besetzt. Der neue GUIDO wird jedoch nur für den Rest der Amtszeit des ursprünglichen GUIDO dienen, an dessen Ende eine neue Wahl durchgeführt wird. Der zurücktretende GUIDO kann bis zur Auswahl seines Nachfolgers weiterhin im Amt bleiben.

Während der Übergangszeit kann der CoP (siehe unten) die Aufgaben des GUIDO wahrnehmen, er kann es jedoch auch vorziehen, substanzielle Entscheidungen (wie z. B. technische PEP-Genehmigungen) dem neu ernannten GUIDO zu überlassen.

Auswahl eines GUIDO

Der Auswahlprozess wird ausgelöst, wann immer eine Vakanz für einen neuen GUIDO besteht oder wenn der GUIDO im normalen Verlauf der Ereignisse zur Wiederwahl ansteht. Wenn der Auswahlprozess ausgelöst wird, entweder durch den Rücktritt des GUIDO oder zwei Monate vor Ablauf der regulären Amtszeit des GUIDO, beginnt ein neues Wahlverfahren.

Drei Wochen vor der Abstimmung sind Nominierungen möglich. Kandidaten müssen aus der aktuellen Liste der Python-Kernentwickler stammen. Nicht-Kernentwickler sind nicht berechtigt, als GUIDO zu fungieren. Kandidaten können sich selbst nominieren, aber alle Nominierungen müssen von jemandem unterstützt werden. Nominierungen und Unterstützungen erfolgen als Merge-Anfragen in einem privaten Repository.

Nachdem sie ihre Nominierung angenommen haben, können die Nominierten kurze Positionsaussagen über dasselbe private Repository posten und sie auch im Diskussionsforum für Committer veröffentlichen. Vielleicht werden wir sogar Debatten haben! Diese Phase der Wahl läuft zwei Wochen.

Kernentwickler haben dann drei Wochen Zeit, gemäß dem in PEP 8001 beschriebenen Verfahren abzustimmen.

Der Rat der Pythonistas (CoP)

Den GUIDO unterstützt ein kleines Team von gewählten Python-Experten. Sie arbeiten im technischen Komitee. Sie bieten Einblicke und diskutieren die Entscheidungen vor dem GUIDO. Konsultationen können von beiden Seiten ausgelöst werden. Wenn der GUIDO beispielsweise bei einer bestimmten Wahl noch unentschlossen ist, können Diskussionen mit dem CoP helfen, die verbleibenden Probleme zu klären, die richtigen Fragen zu identifizieren und Einblicke in die Auswirkungen auf andere Python-Benutzer zu geben, mit denen der GUIDO möglicherweise nicht so vertraut ist. Der CoP ist der vertrauenswürdige Berater des GUIDO, und eine enge Arbeitsbeziehung wird erwartet.

Der CoP besteht aus 3 Mitgliedern, die aus den Kernentwicklern gewählt werden. Ihre Amtszeit beträgt 3 Jahre und Mitglieder können sich beliebig oft zur Wiederwahl stellen. Um die Kontinuität zu gewährleisten, werden CoP-Mitglieder rotierend gewählt; jedes Jahr steht ein CoP-Mitglied zur Wiederwahl.

Um die Staffelung für die Anfangswahl zu ermöglichen, dient das CoP-Mitglied mit den meisten Stimmen für 3 Jahre, der zweitplatzierte Kandidat für 2 Jahre und das CoP-Mitglied mit den wenigsten Stimmen dient zunächst für 1 Jahr.

Alle Gleichstände bei der Abstimmung werden nach einem in PEP 8001 zu bestimmenden Verfahren aufgelöst.

Das Nominierungs- und Abstimmungsverfahren ist ähnlich wie beim GUIDO. Es gibt eine dreiwöchige Nominierungsfrist, in der Selbstnominierungen zulässig sind und unterstützt werden müssen, gefolgt von einer Frist für die Veröffentlichung von Positionsaussagen und dann einer Abstimmung.

Durch einstimmigen Beschluss kann der CoP eine Misstrauensabstimmung gegen den GUIDO einleiten, wodurch das Verfahren in diesem Abschnitt ausgelöst wird.

Misstrauensvoten

Wie oben erwähnt, kann der CoP mit einstimmigem Beschluss eine Misstrauensabstimmung gegen den GUIDO einleiten. Dieses Verfahren sollte nicht leichtfertig unternommen werden, aber sobald es begonnen hat, löst es bis zu zwei Abstimmungen aus. In beiden Fällen wird die Abstimmung nach dem gleichen Verfahren wie in PEP 8001 durchgeführt, und alle Kernentwickler können an Misstrauensabstimmungen teilnehmen.

Die erste Abstimmung betrifft die Absetzung des aktuellen GUIDO. Sollte eine Supermehrheit der Python-Entwickler mit „Misstrauen“ stimmen, wird der GUIDO abgesetzt. Anschließend wird eine zweite Abstimmung durchgeführt, um den neuen GUIDO gemäß den Verfahren für die anfängliche Auswahl dieses Amtsträgers zu wählen. Während der Zeit, in der es keinen GUIDO gibt, werden wichtige Entscheidungen zurückgestellt, aber der normale Python-Betrieb kann natürlich fortgesetzt werden.

Tagesgeschäft

Der GUIDO wird nicht für alle – oder sogar die meisten – Entscheidungen benötigt. Python-Entwickler haben bereits genügend Möglichkeiten zur Delegation, Verantwortung und Selbstbestimmung. Der Issue Tracker und Pull-Requests erfüllen exakt die gleiche Funktion wie vor der Wahl dieses Governance-Modells. Die meisten Diskussionen über Fehlerbehebungen und kleinere Verbesserungen können wie immer auf diesen Foren stattfinden.

PEP-Überlegungen

Der GUIDO, die Mitglieder des CoP und alle anderen in der Python-Gemeinschaft können eine PEP vorschlagen. Die Behandlung der potenziellen PEP erfolgt unabhängig vom Autor der PEP auf die gleiche Weise.

Im Falle, dass der GUIDO eine PEP verfasst, sollte jedoch ein unparteiischer PEP-Delegierter ausgewählt und mit der Befugnis ausgestattet werden, die PEP anzunehmen oder abzulehnen. Der GUIDO sollte sich aus dem Entscheidungsprozess zurückziehen. Im Falle kontroverser PEPs, bei denen kein klarer Konsens erzielt wird, liegt die endgültige Autorität bei kontroversen PEPs, die vom GUIDO verfasst wurden, beim CoP.

Die vorgeschlagene PEP wird weiter verbessert, indem ein Kernentwickler immer als PEP-Shepherd ausgewählt wird. Diese Person stellt sicher, dass die richtige Prozedur eingehalten wird. Der Shepherd muss aus den Reihen der Kernentwickler gewählt werden. Das bedeutet, dass zwar jeder eine PEP verfassen kann, aber alle PEPs ein gewisses Maß an Unterstützung von mindestens einem Kernentwickler erhalten müssen.

Versionshistorie

Version 2

• Umbenannt in „Das Governance-Modell des technischen Leiters“
• „einzelner Leiter“ → „einzelner technischer Leiter“
• Die Übernahme der Abstimmungsverfahren von PEP 8001 ist vorläufig, bis diese PEP genehmigt ist
• Beschreibung, was passiert, wenn der GUIDO zurücktritt
• Abstimmungen zur Absetzung erfordern eine Supermehrheit der Kernentwickler, um erfolgreich zu sein

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.