Schlüsselpersonen und ihre Funktionen

Der Rat der Prüfer (CoA) ist ein Rat unterschiedlicher Größe, typischerweise zwei bis vier Personen, der für die Dauer einer Python-Version gewählt wird. Ein Mitglied des CoA gilt als Präsident, der einige geringfügige Befugnisse über die anderen Mitglieder hat.

Der CoA ist für die Überprüfung kontroverser Entscheidungen in Form von PEPs zuständig, die von Mitgliedern des Kernentwicklungsteams verfasst wurden. Der CoA kann eine PEP genau so, wie sie vorgelegt wurde, akzeptieren oder Klarstellungen oder Änderungen anfordern. Diese Änderungen können jeglicher Art und aus beliebigem Grund sein. Diese Flexibilität ist beabsichtigt und ermöglicht es dem Prozess, sich im Laufe der Zeit mit unterschiedlichen Mitgliedern im CoA zu verändern. Siehe die späteren Abschnitte dieses Dokuments für Beispiele der erwarteten Anfragen.

Der CoA äußert sich nur zu PEPs, die an python-committers eingereicht werden. Es wird nicht erwartet, dass der CoA andere Mailinglisten verfolgt oder daran teilnimmt. (Dies impliziert, dass nur Kernentwickler PEPs einreichen können. Nicht-Kernentwickler können Vorschläge auf anderen Mailinglisten verfassen und diskutieren, aber ohne die Bereitschaft eines Kernentwicklers, den Vorschlag durch eine Aufforderung zur Stellungnahme zu unterstützen, kann er nicht zur Annahme fortschreiten. Dies ist im Wesentlichen dasselbe wie das aktuelle System, wird hier aber explizit gemacht, um sicherzustellen, dass von den Mitgliedern des CoA nicht erwartet wird, sich mit Vorschlägen zu befassen, die nicht von mindestens einem Kernentwickler unterstützt werden.)

Der CoA darf keine Befugnisse an Personen delegieren, die nicht vom Kernentwicklungsteam gewählt wurden. (Ein relevanter Fall hier ist, dass dies die Implementierung des bestehenden BDFL-Delegate-Systems ändert, ohne jedoch notwendigerweise den Geist dieses Systems zu ändern. Siehe die späteren Abschnitte, insbesondere Szenario vier, für weitere Diskussionen zu diesem Punkt.)

Der Release Manager (RM) hat ebenfalls die Befugnis, Änderungen an PEPs anzufordern, die die von ihm verantwortete Version betreffen. Nach dem Feature Freeze behält der RM diese Verantwortung für seine Version, während der CoA rotiert und beginnt, sich auf die nachfolgende Version zu konzentrieren. Dies unterscheidet sich nicht vom aktuellen Prozess. Der Prozess zur Auswahl eines RM wird in diesem Vorschlag nicht geändert.

Kernentwickler sind für die Wahl der Mitglieder des CoA verantwortlich und können eine „Vertrauensentzugswahl“ gegen ein Mitglied des CoA einleiten. Die Details dieser Abstimmungen werden in einem späteren Abschnitt besprochen.

Wenn Diskussionen zwischen Kernentwicklern und Mitgliedern des CoA als fortlaufend, aber unfruchtbar erscheinen, kann der Präsident eingreifen, um eine der beiden Parteien zu überstimmen. Wenn die Diskussion den Präsidenten betrifft, sollte dies über eine Vertrauensentzugswahl gehandhabt werden.

Mitglieder des CoA können jederzeit zurücktreten. Wenn mindestens zwei Mitglieder des CoA verbleiben, können sie eine Neuwahl beantragen, um die Gruppe aufzufüllen. Wenn nur noch ein Mitglied verbleibt, wird die Wahl automatisch ausgelöst. (Das Szenario, in dem der Präsident zurücktritt, wird in einem späteren Abschnitt beschrieben.)

Das beabsichtigte Machtgleichgewicht besteht darin, dass die Kernentwickler Mitglieder des CoA wählen, die die Richtung des Entwicklungsteams widerspiegeln und das Vertrauen des Teams genießen, und die auch die Möglichkeit haben, Mitglieder zu entfernen, die vor der Wahl eingegangene Verpflichtungen nicht erfüllen.

Regelmäßiger Entscheidungsprozess

Reguläre Entscheidungen werden weiterhin wie bisher getroffen.

Zur Klarstellung: Kontroverse Entscheidungen erfordern eine PEP, und alle Entscheidungen, die eine PEP erfordern, gelten als kontrovers.

Der CoA kann gebeten werden, Ratschläge zu geben, ob eine Entscheidung besser im Rahmen des Prozesses für kontroverse Entscheidungen getroffen werden sollte, oder einzelne Mitglieder des CoA können einen solchen Vorschlag anbieten, aber das Kernentwicklungsteam ist an diese Ratschläge nicht gebunden.

Kontroverser Entscheidungsprozess

Kontroverse Entscheidungen werden immer als PEPs verfasst, die dem bestehenden Prozess folgen. Der Genehmiger (früher „BDFL-Delegate“) ist immer der CoA und kann nicht mehr delegiert werden. Beachten Sie, dass dies den CoA nicht daran hindert, einen Kernentwickler zu nominieren, um den Vorschlag zu bewerten und dem CoA eine Empfehlung zu geben, was im Wesentlichen dem aktuellen Delegationsprozess entspricht.

Der CoA wird über PEPs abstimmen, die mit einer Aufforderung zur Stellungnahme an python-committers eingereicht werden. Jedes Mitglied des CoA oder der aktuelle RM kann aus beliebigem Grund Änderungen an einer PEP beantragen, vorausgesetzt, sie geben eine gewisse Angabe darüber, welche zusätzlichen Arbeiten erforderlich sind, um ihre Erwartungen zu erfüllen. Siehe spätere Abschnitte für Beispiele erwarteter Gründe.

Wenn alle Mitglieder des CoA und der RM angeben, dass sie keine Bedenken hinsichtlich einer PEP haben, wird diese formell angenommen. Wenn ein oder mehrere Mitglieder des CoA längere Zeit nicht reagieren, kann der Präsident des CoA dies als stillschweigende Zustimmung interpretieren. Das Versäumnis des Präsidenten zu reagieren sollte durch eine Vertrauensentzugswahl behandelt werden.

Amtszeiten der Wahlen

Mitglieder des CoA werden für die Dauer einer Veröffentlichung gewählt. Die Mitglieder werden vor dem Feature Freeze der vorherigen Veröffentlichung gewählt und behalten ihre Position bis zum Feature Freeze ihrer Veröffentlichung.

Mitglieder können sich beliebig oft zur Wiederwahl stellen. Es gibt keine Amtszeitbeschränkungen. Es obliegt den Kernentwicklern, die Wiederwahl der CoA-Mitglieder zu verhindern, wenn ein Konsens darüber besteht, dass die Person nicht erneut dienen sollte.

Wahlprozess

Der Wahlprozess für jedes Mitglied des CoA verläuft wie folgt:

• Eine Nominierungs-E-Mail wird an python-committers gesendet
• Eine Bestätigungs-E-Mail wird gesendet
• Der Kandidat wird vorläufig zu python-committers hinzugefügt, um sich vorzustellen und seine Position darzulegen
• Die Abstimmung beginnt zwei Wochen vor dem geplanten Feature Freeze der vorherigen Veröffentlichung
• Stimmen werden durch Änderung eines Dokuments in einem privaten GitHub-Repository abgegeben
• Jeder Kernentwickler kann +1-Stimmen für beliebig viele Kandidaten abgeben
• Nach sieben Tagen schließt die Abstimmung
• Der Kandidat mit den meisten Stimmen wird zum Präsidenten des CoA gewählt
• Die nächsten drei Kandidaten mit den meisten Stimmen und mindestens 50 % der vom Präsidenten erhaltenen Stimmen werden zu den anderen Mitgliedern des CoA gewählt
• Bei Stimmengleichheit kann der RM eine zusätzliche Stimme für seine bevorzugten Kandidaten abgeben
• Akzeptierte Kandidaten bleiben auf python-committers; andere werden entfernt

Prozess der Vertrauensentzugswahl

Eine Vertrauensentzugswahl verläuft wie folgt:

• Eine E-Mail zur Vertrauensentzugswahl wird an python-committers gesendet, die das betroffene Mitglied des CoA benennt, die Nominierung begründet und optional akzeptierte PEPs auflistet, die der Nominierende zurückgenommen sehen möchte.
• Innerhalb von sieben Tagen wird eine Bestätigungs-E-Mail gesendet
• Das nominierte Mitglied des CoA darf sieben Tage zur Antwort aufgeben, danach können der Nominierende oder der Bestätigende zurücktreten.
• Wenn kein Nominierender oder Bestätigender verfügbar ist, werden keine weiteren Maßnahmen ergriffen.
• Die Abstimmung beginnt sofort
• Jeder Kernentwickler kann eine +1-Stimme (CoA-Mitglied entfernen) oder eine -1-Stimme (CoA-Mitglied behalten) abgeben, indem er ein Dokument in einem privaten GitHub-Repository bearbeitet.
• Nach sieben Tagen schließt die Abstimmung
• Wenn die +1-Stimmen die -1-Stimmen übersteigen, wird das CoA-Mitglied von python-committers entfernt und alle nominierten PEPs werden zurückgenommen.
• Wenn von den verbleibenden Mitgliedern des CoA verlangt oder wenn nur noch ein Mitglied des CoA verbleibt, kann eine Neuwahl zur Ersetzung des entfernten Mitglieds nach dem üblichen Verfahren durchgeführt werden.
• Im Falle der Entfernung des Präsidenten des CoA wird der Kandidat, der ursprünglich die zweitmeisten Stimmen erhalten hat, zum Präsidenten ernannt.

Szenario 1 – Der Fall einer vagen PEP

In der Vergangenheit fehlte es anfänglichen Vorschlägen oft an ausreichenden Details, um von anderen als dem Antragsteller umgesetzt werden zu können. Um dies zu vermeiden, sollte der CoA Vorschläge bei der Einreichung „frisch“ und ohne Schlussfolgerungen oder impliziten Kontext lesen. Wenn dann ein Aspekt einer PEP unklar ist, kann der CoA den Vorschlag ablehnen und Klarstellungen verlangen.

Da der Vorschlag abgelehnt wird, muss er modifiziert und erneut eingereicht werden, um erneut geprüft zu werden. Der CoA entscheidet, wie viel Anleitung er bei der Ablehnung der PEP gibt, da dies beeinflusst, wie oft sie wahrscheinlich erneut eingereicht wird (und somit die eigene Arbeitsbelastung des CoA beeinflusst). Dies stellt sicher, dass der endgültige PEP-Text eigenständig mit allen erforderlichen Informationen steht.

Szenario 2 – Der Fall einer endlosen Diskussion

Von Zeit zu Zeit kann eine Diskussion zwischen Python-Beitragenden keinen Mehrwert mehr bieten. Zum Beispiel, wenn eine große Anzahl von E-Mails Punkte wiederholt, die bereits behandelt wurden, oder wenn sie aktiv feindselig gegenüber anderen sind, hat es keinen Sinn, die „Diskussion“ fortzusetzen.

Wenn eine solche Diskussion auf python-committers im Rahmen einer Aufforderung zur Stellungnahme stattfindet, sollte ein Mitglied des CoA den Thread einfach beenden, indem es den Vorschlag ablehnt. In den meisten bekannten Fällen deutet eine solche Diskussion darauf hin, dass nicht alle Bedenken im Vorschlag ausreichend berücksichtigt wurden und der Autor möglicherweise einige Abschnitte verbessern muss.

Alternativ und in Abwesenheit einer Ablehnung durch die anderen Mitglieder des CoA kann der Präsident den Thread durch Annahme des Vorschlags beenden. Idealerweise würde dies geschehen, nachdem er sich direkt mit dem Rest des CoA und dem RM vergewissert hat, dass keine Bedenken bestehen.

Wenn eine solche Diskussion auf einer anderen Liste stattfindet, sollten die Mitglieder des CoA als respektierte Stimmen ähnlich wie andere Kernentwickler (insbesondere die Kernentwickler, die als Experten für den Themenbereich benannt sind) betrachtet werden. Obwohl keiner spezifische Autorität hat, einen Thread zu beenden, ist die präventive Äußerung der Absicht, einen Vorschlag zu blockieren, ein nützliches Mittel, um potenziell nutzlose Diskussionen zu entschärfen. Mitglieder des CoA, die freiwillig andere Diskussionen als auf python-committers verfolgen, dürfen dem Antragsteller vorschlagen, zurückzuziehen, können aber einen Vorschlag, der formell zur Stellungnahme eingereicht wird, nur tatsächlich genehmigen oder ablehnen.

Szenario 3 – Der Fall der unberücksichtigten Benutzer

Einige frühere Vorschläge wurden möglicherweise verfasst und zur Stellungnahme eingereicht, ohne die Auswirkungen auf bestimmte Benutzergruppen zu berücksichtigen. Beispielsweise könnte ein Vorschlag, der die für die Verwendung von Python auf verschiedenen Maschinen erforderlichen Abhängigkeiten betrifft, negative Auswirkungen auf einige Benutzer haben, auch wenn viele nicht betroffen sind, da die Abhängigkeiten standardmäßig verfügbar sind.

Wenn ein Vorschlag nicht alle Benutzer zu berücksichtigen scheint, kann der CoA sein Urteilsvermögen und seine Erfahrungen nutzen, um festzustellen, dass mehr Benutzer von der Änderung betroffen sind als in der PEP beschrieben, und verlangen, dass die PEP auch diese Benutzer anspricht. Sie sollten die Gruppe der Benutzer klar genug identifizieren, damit der Antragsteller diese Benutzer ebenfalls identifizieren kann, und entweder klären, wie sie angesprochen wurden, oder Änderungen an der PEP vornehmen, um sie explizit anzusprechen. (Beachten Sie, dass dies nicht die Bewertung der Nützlichkeit der Funktion für verschiedene Benutzergruppen beinhaltet, sondern nur, ob die PEP angibt, ob die Nützlichkeit der Funktion bewertet wurde.)

Wenn ein Vorschlag fehlerhafte Logik oder falsche Daten verwendet zu haben scheint, um zu einer bestimmten Schlussfolgerung zu gelangen, kann der CoA andere Informationsquellen (wie die vorherige Diskussion oder eine Einreichung von anderen Kernentwicklern) nutzen, um die Überprüfung bestimmter Punkte zu verlangen. Der Antragsteller muss nicht unbedingt die vom CoA erhaltenen Informationen verwenden, um seinen Vorschlag zu aktualisieren, vorausgesetzt, die vorgenommenen Änderungen sind für den CoA zufriedenstellend. Zum Beispiel kann eine PEP angeben, dass 30 % der Benutzer betroffen wären, während der CoA argumentieren könnte, dass 70 % der Benutzer betroffen sind. Eine erfolgreiche Änderung könnte einen anderen, aber zuverlässigeren Prozentsatz enthalten oder umgeschrieben werden, um nicht mehr von der Anzahl der betroffenen Benutzer abhängig zu sein.

Szenario 4 – Der Fall der delegierten Entscheidung

Einige Vorschläge erfordern möglicherweise eine Überprüfung und Genehmigung durch einen Spezialisten auf dem Gebiet. Historisch gesehen wären diese durch die Ernennung eines BDFL-Delegierten zur endgültigen Entscheidung über den Vorschlag gehandhabt worden. In diesem Modell kann der CoA jedoch den endgültigen Entscheidungsprozess nicht delegieren. Wenn der CoA der Meinung ist, dass ein Fachexperte über einen bestimmten Vorschlag entscheiden sollte, kann der CoA eine oder mehrere Personen nominieren (oder deren Selbstnominierung akzeptieren) für eine Position, die einem BDFL-Delegierten ähnelt. Die Bedingungen für die Rolle dieser Experten können vom CoA festgelegt werden, obwohl der CoA immer die endgültige Genehmigung behält.

Als konkretes Beispiel nehmen wir an, ein Vorschlag wird über ein neues Sprachmerkmal diskutiert. Befürworter behaupten, dass dies die Sprache für neue Entwickler einfacher zu erlernen machen wird. Noch vor einer offiziellen Einreichung kann der CoA angeben, dass er den Vorschlag nicht akzeptiert, es sei denn, Person X stimmt zu, da Person X eine lange Geschichte im Unterrichten von Python hat und ihrem Urteil vertraut wird. (Beachten Sie, dass Person X kein Kernentwickler sein muss.)

Nachdem Person X diese Rolle erhalten hat, kann sie die Diskussion vorantreiben und sie schnell auf praktikable Alternativen konzentrieren. Schließlich wählt Person X die Alternative, mit der sie am zufriedensten ist, und teilt dem CoA mit, dass sie zustimmt. Der Vorschlag wird wie üblich eingereicht, und der CoA prüft und akzeptiert ihn unter Berücksichtigung der Meinung von Person X.