Zusammenfassung

Dieses PEP schlägt ein Governance-Modell mit so wenigen Verfahren, definierten Begriffen und Prozentzahlen wie möglich vor. Es könnte auch als Das Anarchistische Governance Model bezeichnet werden, verwendet aber vorerst Commons wegen möglicher negativer Konnotationen des Begriffs Anarchistisch für einige Zielgruppen.

Die Grundidee ist, dass alle Entscheidungen grundsätzlich von der gesamten Gemeinschaft abgestimmt werden, in der Praxis aber nur von einer Teilmenge der Gemeinschaft. Eine Teilmenge, denn obwohl die gesamte Gemeinschaft stimmberechtigt ist, wird es in der Praxis immer nur eine kleine Teilmenge sein, die über eine bestimmte Entscheidung abstimmt. Die Abstimmung wird von einem unparteiischen Rat überwacht, der beurteilt, ob die Entscheidung bestanden hat oder nicht. Die Absicht ist, dass dieser Rat seine Entscheidung nicht nur auf das Verhältnis von Ja- und Nein-Stimmen stützt, sondern auch auf die Gesamtzahl der Stimmen, auf die Schwere des zur Abstimmung stehenden Vorschlags und möglicherweise auf die einzelnen Wähler und wie sie abgestimmt haben. Dadurch wird dieser Rat dafür verantwortlich, dass jede einzelne Entscheidung von einer ausreichenden Mehrheit getragen wird.

Ablehnung der PEP

PEP 8014 wurde von einer Kernentwickler-Abstimmung abgelehnt, die in PEP 8001 am Montag, 17. Dezember 2018, beschrieben wurde.

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

Einleitung

Das Commons Governance Model versucht sicherzustellen, dass alle Entscheidungen von einer ausreichenden Mehrheit der Python-Community unterstützt werden oder zumindest für diese akzeptabel sind.

Leider gibt es im vorherigen Absatz zwei Begriffe, die im Allgemeinen schwer zu quantifizieren sind: ausreichende Mehrheit und Python-Community. Dies liegt daran, dass beide Begriffe in der Realität vom spezifischen Fall abhängen, über den entschieden wird. Um ein Beispiel für diese Schwierigkeit zu geben: Für ein PEP, das eine abwärtskompatible Änderung an einer API vorschlägt, ist eine einfache Mehrheit der Kernentwickler, die sich überhaupt für die Abstimmung über das PEP interessierten, wahrscheinlich ausreichend. Aber für eine Änderung mit weitreichenderen Konsequenzen, wie z. B. einen Übergang von Python 3 zu Python 4, könnte eine echte Mehrheit gewünscht sein, und ein Nachweis, dass es zumindest eine ausreichende Unterstützung in der Benutzerbasis zu geben scheint. Und für eine Änderung, die über Python als Sprache hinausgeht, wie z. B. Entscheidungen über die Abschaffung nicht-inklusiver Sprache, wird es sehr vage.

Das Commons Governance Model versucht, dieses Problem zu umgehen, indem es nicht definiert, was die Begriffe ausreichende Mehrheit und Python-Community im Allgemeinen bedeuten, indem es ein Gremium vorschlägt, das dies in spezifischen Fällen entscheiden wird.

Das Modell schlägt die Schaffung eines Ältestenrats vor, der den Entscheidungsprozess überwacht und von Fall zu Fall entscheidet, ob ein bestimmter Vorschlag genügend Unterstützung hat. Bei jedem einzelnen PEP wird es eine Abstimmung geben, und der Ältestenrat wird erklären, ob das Ergebnis der Abstimmung ausreicht, um die Entscheidung in diesem spezifischen Fall zu tragen.

Das Modell befasst sich nur mit den traditionell vom BDFL wahrgenommenen Rollen im Entscheidungsprozess, nicht mit anderen Rollen.

Der Begriff Commons im Modellnamen basiert lose auf seiner historischen Verwendung als gemeinsames Gut, das von allen genutzt und von allen gepflegt wird. Das Bild, das man sich bei diesem Modell vorstellen sollte, ist eine beträchtliche Gruppe von Bauern, die am Rande des Dorfes an einem warmen Sommerabend über einen Plan für die Zukunft diskutieren, woraufhin abgestimmt wird und die Dorfältesten das Ergebnis verkünden. Danach beginnt das Bankett.

Das Commons Governance Model unterscheidet sich von den meisten anderen Governance-Vorschlägen (mit der möglichen Ausnahme von 8012), da es die oberste Macht ausdrücklich bei der gesamten Gemeinschaft ansiedelt.

Begründung

Die Begründung für das Modell ist, dass ein Modell, das alles in Stein meißelt, unbeabsichtigte negative Nebenwirkungen haben wird. Zum Beispiel kann ein Governance-Modell, das Python-Committern Stimmrechte zuweist, dazu führen, dass eine Person nicht als Committer akzeptiert wird, weil es bereits viele Committer aus dem Unternehmen gibt, für das der neue Kandidat arbeitet.

Als weiteres Beispiel kann die Festlegung eines festen Prozentsatzes für die PEP-Akzeptanz zur Parteibildung unter den Wählern führen, und einzelne PEPs werden nicht mehr nach individuellen Verdiensten, sondern nach Parteilinien beurteilt (wenn du mein PEP unterstützt, unterstütze ich deines).

Es gibt auch die Frage, dass "eine Person, eine Stimme" nicht das beste Modell für etwas wie Python ist. Wieder ein Beispiel: Bei einer gespaltenen Abstimmung (oder einer Abstimmung, die ausreichend nah an einer Spaltung ist) sollte die Meinung des Kernentwicklers Guido van Rossum wahrscheinlich mehr wiegen als die Meinung des Kernentwicklers Jack Jansen. Der Versuch, dies in einem Abstimmungsmodell zu formalisieren, führt zu einem sehr komplexen Modell, das in Grenzfall-Situationen ohnehin falsch sein wird. Das hier vorgestellte Modell überlässt die Entscheidung über solche Fragen dem (hoffentlich vernünftigen) Ältestenrat.

Entscheidungsprozess

Alle wichtigen Entscheidungen durchlaufen einen PEP-Prozess. Jedes PEP hat eine verantwortliche Person, hier Autor genannt, aber das muss keine einzelne Person sein, und es muss nicht die Person sein, die den Text tatsächlich geschrieben hat. Daher könnte man statt Autor auch Champion oder Shepherd oder etwas Ähnliches lesen.

Der PEP-Autor ist für die Organisation einer Abstimmung über das PEP verantwortlich. Diese Abstimmung ist öffentlich, d.h. die Wähler sind identifiziert und die Ergebnisse sind allen bekannt. Die Abstimmung kann einfach +1/0/-1 sein, kann aber auch mit +2/-2 erweitert werden, mit einer sehr knappen Erklärung, warum der Wähler eine starke Meinung zu dem Thema hat. Eine solche Anmerkung würde als Erklärung für den Ältestenrat dienen. Wähler werden mit ihrem Community-Status (Kernentwickler, etc.) annotiert.

Die Abstimmung ist klar von der Diskussion getrennt, indem eine gut definierte Discourse-Kategorie oder ein Tag, eine spezielle Mailingliste oder eine ähnliche technische Methode verwendet wird (z. B. eine Website vote.python.org, auf der sich die Leute anmelden müssen, damit ihr Community-Status automatisch hinzugefügt und ihre Identität einigermaßen bestätigt werden kann).

Der PEP-Autor legt das PEP und die Abstimmungsergebnisse dem Ältestenrat vor. Der Rat bedenkt zwei Dinge:

• die Schwere des PEP und seine Auswirkungen,
• die messbaren Abstimmungsergebnisse (wie viele Leute haben abgestimmt, welche Personen haben abgestimmt, was sie abgestimmt haben).

Sie verkünden eine vorläufige Entscheidung, ob die Abstimmung bestanden wurde, und diese Entscheidung wird veröffentlicht.

Wenn die Entscheidung lautet, dass die Abstimmungsergebnisse nicht genügend Unterstützung aus der Community für die Entscheidung zeigen, liegt es am Autor, mehr Unterstützung zu sammeln und die Abstimmung zu einem späteren Zeitpunkt erneut einzureichen. Alternativ kann der Autor den Vorschlag zurückziehen. Die Frist für das Sammeln weiterer Unterstützung ist zeitlich begrenzt, ein Monat scheint eine angemessene Zeit, wenn nach dieser Frist keine Abstimmung erneut eingereicht wurde, ist der Vorschlag abgelehnt.

Wenn die vorläufige Entscheidung lautet, dass die Ergebnisse genügend Unterstützung zeigen, beginnt eine ziemlich kurze Wartezeit (in der Größenordnung von Wochen). Während dieser Zeit kann jeder an den Ältestenrat appellieren, aber nur mit der Begründung, dass die Abstimmung keine ausreichende Mehrheit der Community widerspiegelt. Nach Ablauf der Wartezeit verkündet der Rat eine endgültige Entscheidung. Das PEP wird entweder angenommen oder, wenn der Rat einem Einspruch nachgibt, kehrt es in den Zustand zurück, in dem mehr Unterstützung gezeigt werden muss.

Ältestenrat

Die Absicht des Ältestenrats ist es, dass sie gemeinsam in der Lage sind zu beurteilen, ob der Wille der Python-Community in einer bestimmten Abstimmung gewahrt bleibt.

Der Ältestenrat ist kein Ersatz für den BDFL durch eine Gruppe von Personen mit der gleichen Macht wie der BDFL: Er gibt keine Anleitung zur Richtung von Python, er versucht nur sicherzustellen, dass das Ergebnis einer Abstimmung den Willen der Community widerspiegelt.

Der Ältestenrat ist nicht wie der Oberste Gerichtshof der USA, der tatsächliche Entscheidungsbefugnis hat. Der Rat überwacht nur den Abstimmungsprozess, um sicherzustellen, dass die Community in der Abstimmung vertreten ist. Und der Ältestenrat ist definitiv nicht wie die spanische Inquisition, denn Angst, Überraschung und rücksichtslose Effizienz sind Dinge, auf die wir verzichten können (aber es gibt einen gewissen Vorteil darin, die niedliche rote Robe zu tragen).

Der Rat ist etwas wie der niederländische Hoge Raad (der im Englischen leider oft als Oberster Gerichtshof übersetzt wird), da er den Prozess und die befolgten Verfahren beurteilt und Fälle nur zur erneuten Beurteilung zurückverweisen kann.

Er ähnelt auch etwas der Wahlkommission, die viele Länder (unter verschiedenen Namen) haben, da sie Wahlen überwacht.

Diskussion

Dieses PEP behandelt andere Rollen des BDFL nicht, nur den Abstimmungsprozess. Am wichtigsten ist, dass die langfristige Ausrichtung von Python nicht vom Ältestenrat erwartet wird. Dies liegt in der Verantwortung der gesamten Community (oder wahrscheinlich einzelner Mitglieder der Community).

Es gibt auch die Rolle als Galionsfigur oder Sprecher, um Python und die Python-Community nach außen zu vertreten. Auch dies ist meiner Meinung nach keine Rolle, die vom Ältestenrat wahrgenommen werden sollte, sondern von einer anderen Person oder einem anderen Gremium.

Beachten Sie, dass dieser Vorschlag wahrscheinlich den Konservatismus gegenüber dem Fortschritt bevorzugt. Oder zumindest ist die Gefahr, dass er zu Stagnation führt, größer als die Gefahr, dass er zu rücksichtslosen Vorstößen in unbekannte Gebiete führt. Also: Wir sollten uns bewusst sein, dass es unwahrscheinlich ist, dass ein PEP wie PEP 572 mit diesem Modell verabschiedet wird.

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.