PEP 8016 – Das Steering Council Modell
- Autor:
- Nathaniel J. Smith, Donald Stufft
- Status:
- Akzeptiert
- Typ:
- Informational
- Thema:
- Governance
- Erstellt:
- 01-Nov-2018
Inhaltsverzeichnis
Hinweis
Diese PEP wird aus historischen Gründen beibehalten, aber das offizielle Governance-Dokument ist jetzt PEP 13.
Zusammenfassung
Diese PEP schlägt ein Modell der Python-Governance vor, das auf einem Steering Council basiert. Der Council hat weitreichende Befugnisse, die er so selten wie möglich ausüben möchte; stattdessen nutzt er diese Macht, um Standardprozesse zu etablieren, wie sie in den anderen PEPs der 801x-Serie vorgeschlagen werden. Dies folgt der allgemeinen Philosophie, dass es besser ist, große Änderungen in eine Reihe kleiner Änderungen aufzuteilen, die unabhängig überprüft werden können: Anstatt zu versuchen, alles in einer PEP zu erledigen, konzentrieren wir uns darauf, eine minimale, aber solide Grundlage für weitere Governance-Entscheidungen zu schaffen.
PEP-Akzeptanz
PEP 8016 wurde am Montag, 17. Dezember 2018, durch eine Abstimmung der Core-Entwickler angenommen, die in PEP 8001 beschrieben ist.
Begründung
Die Hauptziele dieses Vorschlags sind:
- Langweilig sein: Wir sind keine Governance-Experten und glauben nicht, dass Python ein guter Ort ist, um mit neuen und unerprobten Governance-Modellen zu experimentieren. Daher hält sich dieser Vorschlag so weit wie möglich an ausgereifte, bekannte und bereits getestete Prozesse. Der übergeordnete Ansatz eines weitgehend unabhängigen Councils ist wohl der häufigste bei großen, erfolgreichen F/OSS-Projekten, und die Details auf niedriger Ebene stammen direkt aus der Django-Governance.
- Einfach sein: Wir haben versucht, die Dinge auf das Minimum zu reduzieren, das für die Funktionsfähigkeit erforderlich ist: der Council, das Core-Team (das den Council wählt) und der Prozess zur Änderung des Dokuments. Das Ziel ist Minimum Viable Governance.
- Umfassend sein: Aber für die Dinge, die wir definieren müssen, haben wir versucht, alle Aspekte abzudecken, weil wir nicht noch einmal eine solche Krise durchmachen wollen. Ein klares und eindeutiges Regelwerk hilft auch, Verwirrung und Groll zu minimieren.
- Flexibel und schlank sein: Wir wissen, dass es Zeit und Experimente brauchen wird, um die besten Prozesse für die Zusammenarbeit zu finden. Indem wir dieses Dokument so minimal wie möglich halten, behalten wir maximale Flexibilität, um Dinge später anzupassen, und minimieren gleichzeitig die Notwendigkeit von aufwendigen und beunruhigenden Prozessen wie Abstimmungen über das gesamte Projekt.
Eine Reihe von Details wurden in diesem Discourse-Thread diskutiert, und dieser Thread enthält weitere Diskussionen. Diese können für jeden nützlich sein, der die Begründung für verschiedene kleinere Entscheidungen verstehen möchte.
Spezifikation
Das Steering Council
Zusammensetzung
Das Steering Council ist ein 5-köpfiges Komitee.
Mandat
Das Steering Council soll sich bemühen,
- die Qualität und Stabilität der Python-Sprache und des CPython-Interpreters zu erhalten,
- die Mitwirkung so zugänglich, integrativ und nachhaltig wie möglich zu gestalten,
- die Beziehung zwischen dem Core-Team und der PSF zu formalisieren und aufrechtzuerhalten,
- geeignete Entscheidungsprozesse für PEPs zu etablieren,
- Konsens unter Mitwirkenden und dem Core-Team zu suchen, bevor in formaler Funktion gehandelt wird,
- als „letzte Instanz“ für Entscheidungen zu fungieren, bei denen alle anderen Methoden versagt haben.
Befugnisse
Der Council hat weitreichende Befugnisse, um Entscheidungen über das Projekt zu treffen. Zum Beispiel kann er:
- PEPs annehmen oder ablehnen
- den Verhaltenskodex des Projekts durchsetzen oder aktualisieren
- mit der PSF zusammenarbeiten, um Projekteigentum zu verwalten
- Teile seiner Befugnisse an andere Unterausschüsse oder Prozesse delegieren
Er darf jedoch diese PEP nicht ändern oder die Mitgliedschaft des Core-Teams beeinflussen, es sei denn durch die in dieser PEP festgelegten Mechanismen.
Der Council sollte nach Möglichkeiten suchen, diese Befugnisse so wenig wie möglich einzusetzen. Anstatt abzustimmen, ist es besser, Konsens zu suchen. Anstatt über einzelne PEPs zu entscheiden, ist es besser, einen Standardprozess für PEP-Entscheidungen zu definieren (zum Beispiel durch Annahme einer der anderen PEPs der 801x-Serie). Es ist besser, ein Komitee für den Verhaltenskodex einzurichten, als über Einzelfälle zu entscheiden. Und so weiter.
Um seine Befugnisse auszuüben, stimmt der Council ab. Jedes Council-Mitglied muss entweder abstimmen oder sich ausdrücklich enthalten. Mitglieder mit Interessenkonflikten bei einer bestimmten Abstimmung müssen sich enthalten. Zum Bestehen ist die Unterstützung durch eine Mehrheit der nicht enthaltenden Council-Mitglieder erforderlich.
Soweit möglich, sollen die Beratungen und Abstimmungen des Councils öffentlich abgehalten werden.
Wahl des Councils
Eine Council-Wahl besteht aus zwei Phasen:
- Phase 1: Kandidaten werben um Interesse an einer Mitarbeit. Kandidaten müssen von einem Core-Team-Mitglied nominiert werden. Selbstnominierungen sind erlaubt.
- Phase 2: Jedes Core-Team-Mitglied kann für null bis fünf Kandidaten stimmen. Die Abstimmung erfolgt anonym. Die Kandidaten werden nach der Gesamtzahl der erhaltenen Stimmen gerankt. Bei Stimmengleichheit kann diese durch gegenseitige Übereinkunft der Kandidaten gelöst werden, andernfalls wird der Gewinner zufällig bestimmt.
Jede Phase dauert ein bis zwei Wochen, nach Ermessen des scheidenden Councils. Für die erste Wahl dauern beide Phasen zwei Wochen.
Der Wahlprozess wird von einem Wahlleiter verwaltet, der vom scheidenden Steering Council nominiert wird. Für die erste Wahl wird der Wahlleiter vom PSF Executive Director nominiert.
Der Council sollte idealerweise die Vielfalt der Python-Mitwirkenden und -Nutzer widerspiegeln, und die Core-Team-Mitglieder werden ermutigt, entsprechend zu wählen.
Amtszeit
Ein neuer Council wird nach jeder Feature-Release gewählt. Die Amtszeit jedes Councils läuft von der Finalisierung der Wahlergebnisse bis zum Beginn der Amtszeit des nächsten Councils. Es gibt keine Amtszeitbeschränkungen.
Vakanzen
Council-Mitglieder können ihre Position jederzeit niederlegen.
Wenn während der regulären Council-Amtszeit eine Vakanz entsteht, kann der Council abstimmen, einen Nachfolger zu ernennen, der den Rest der Amtszeit ausfüllt.
Wenn ein Council-Mitglied den Kontakt verliert und einen Monat oder länger nicht erreichbar ist, kann der Rest des Councils abstimmen, es zu ersetzen.
Interessenkonflikte
Obwohl wir den Council-Mitgliedern vertrauen, im besten Interesse von Python und nicht in ihrem eigenen oder dem ihrer Arbeitgeber zu handeln, könnte allein der Anschein, dass ein einzelnes Unternehmen die Python-Entwicklung dominiert, schädlich sein und das Vertrauen untergraben. Um jeden Anschein eines Interessenkonflikts zu vermeiden, dürfen höchstens 2 Mitglieder des Councils für denselben Arbeitgeber tätig sein.
Bei einer Rats-/Komiteewahl werden, wenn 3 der 5 bestplatzierten Kandidaten für denselben Arbeitgeber arbeiten, die von ihnen am niedrigsten platzierten disqualifiziert und der 6. Kandidat rückt auf den 5. Platz auf; dies wird wiederholt, bis ein gültiger Rat gebildet ist.
Wenn sich während der Amtszeit des Councils die Umstände ändern und diese Regel gebrochen wird (z. B. weil ein Council-Mitglied den Arbeitgeber wechselt), müssen ein oder mehrere Council-Mitglieder zurücktreten, um das Problem zu beheben, und die daraus resultierenden Vakanzen können dann wie gewohnt besetzt werden.
Ausschluss von Core-Team-Mitgliedern
In Ausnahmefällen kann es notwendig sein, jemanden gegen seinen Willen aus dem Core-Team zu entfernen. (Beispiel: schwerwiegende und fortlaufende Verstöße gegen den Verhaltenskodex.) Dies kann durch eine Abstimmung des Steering Councils erfolgen, erfordert aber im Gegensatz zu anderen Abstimmungen des Steering Councils mindestens eine Zweidrittelmehrheit. Bei 5 stimmberechtigten Mitgliedern bedeutet dies, dass eine 3:2-Abstimmung nicht ausreicht; eine 4:1-Abstimmung zugunsten ist das Minimum, damit eine solche Abstimmung erfolgreich ist. Darüber hinaus ist dies die einzige Befugnis des Steering Councils, die nicht delegiert werden kann, und diese Befugnis kann nicht während eines Misstrauensvotums ausgeübt werden.
Wenn das ausgeschlossene Core-Team-Mitglied auch im Steering Council ist, wird es auch aus dem Steering Council entfernt.
Misstrauensvotum
In Ausnahmefällen kann das Core-Team ein sitzendes Council-Mitglied oder das gesamte Council durch ein Misstrauensvotum entfernen.
Ein Misstrauensvotum wird ausgelöst, wenn ein Core-Team-Mitglied es öffentlich über einen geeigneten Projektkommunikationskanal beantragt und ein anderes Core-Team-Mitglied den Antrag unterstützt.
Die Abstimmung dauert zwei Wochen. Core-Team-Mitglieder stimmen dafür oder dagegen. Wenn mindestens zwei Drittel der Wähler mangelndes Vertrauen ausdrücken, ist die Abstimmung erfolgreich.
Es gibt zwei Formen von Misstrauensvoten: solche, die sich gegen ein einzelnes Mitglied richten, und solche, die sich gegen das Council als Ganzes richten. Der anfängliche Antrag auf ein Misstrauensvotum muss angeben, welche Art beabsichtigt ist. Wenn ein Einzelvotum erfolgreich ist, wird dieses Mitglied aus dem Council entfernt und die daraus resultierende Vakanz kann auf übliche Weise behandelt werden. Wenn ein Gesamt-Council-Votum erfolgreich ist, wird der Council aufgelöst und eine Neuwahl des Councils wird sofort ausgelöst.
Das Kernteam
Rolle
Das Core-Team ist die Gruppe vertrauenswürdiger Freiwilliger, die Python verwalten. Sie übernehmen viele Rollen, die zur Erreichung der Projektziele erforderlich sind, insbesondere solche, die ein hohes Maß an Vertrauen erfordern. Sie treffen die Entscheidungen, die die Zukunft des Projekts gestalten.
Core-Team-Mitglieder sollen als Vorbilder für die Community und als Hüter des Projekts im Namen der Community und aller, die auf Python angewiesen sind, agieren.
Sie greifen bei Bedarf in Online-Diskussionen oder bei offiziellen Python-Veranstaltungen ein, wenn sich selten eine Situation ergibt, die ein Eingreifen erfordert.
Sie haben die Befugnis über die Infrastruktur des Python-Projekts, einschließlich der Python-Projekt-Website selbst, der Python GitHub-Organisation und -Repositorys, des Bug-Trackers, der Mailinglisten, IRC-Kanäle usw.
Vorrechte
Core-Team-Mitglieder können an formellen Abstimmungen teilnehmen, typischerweise um neue Teammitglieder zu nominieren und das Steering Council zu wählen.
Mitgliedschaft
Python Core-Team-Mitglieder zeigen
- ein gutes Verständnis der Philosophie des Python-Projekts
- eine solide Erfolgsbilanz konstruktiven und hilfreichen Verhaltens
- signifikante Beiträge zu den Projektzielen in jeglicher Form
- die Bereitschaft, Zeit für die Verbesserung von Python aufzuwenden
Da das Projekt reift, gehen Beiträge über Code hinaus. Hier ist eine unvollständige Liste von Bereichen, in denen Beiträge für den Beitritt zum Core-Team in Betracht gezogen werden können, in keiner bestimmten Reihenfolge:
- Mitarbeit an Community-Management und Outreach
- Bereitstellung von Unterstützung auf den Mailinglisten und in IRC
- Triage von Tickets
- Schreiben von Patches (Code, Dokumentation oder Tests)
- Überprüfung von Patches (Code, Dokumentation oder Tests)
- Teilnahme an Designentscheidungen
- Bereitstellung von Expertise in einem bestimmten Bereich (Sicherheit, i18n usw.)
- Verwaltung der Continuous-Integration-Infrastruktur
- Verwaltung der Server (Website, Tracker, Dokumentation usw.)
- Pflege verwandter Projekte (alternative Interpreter, Kerninfrastruktur wie Packaging usw.)
- Erstellung von visuellen Designs
Die Mitgliedschaft im Core-Team würdigt anhaltende und wertvolle Bemühungen, die gut mit der Philosophie und den Zielen des Python-Projekts übereinstimmen.
Sie wird durch mindestens zwei Drittel positive Stimmen in einer Abstimmung des Core-Teams und kein Veto durch das Steering Council gewährt.
Core-Team-Mitglieder suchen immer nach vielversprechenden Mitwirkenden, lehren sie, wie das Projekt verwaltet wird, und reichen ihre Namen zur Abstimmung des Core-Teams ein, wenn sie bereit sind.
Es gibt keine Zeitbeschränkung für die Mitgliedschaft im Core-Team. Um jedoch der allgemeinen Öffentlichkeit eine angemessene Vorstellung davon zu geben, wie viele Personen Python pflegen, werden Core-Team-Mitglieder, die ihre Beiträge eingestellt haben, ermutigt, sich als „inaktiv“ zu bezeichnen. Wer in den letzten zwei Jahren keine nicht-triviale Beitrag geleistet hat, kann gebeten werden, sich in diese Kategorie zu verschieben, und wird dorthin verschoben, wenn er nicht reagiert. Um ihre Beiträge aufzuzeichnen und zu ehren, werden inaktive Teammitglieder weiterhin zusammen mit aktiven Core-Team-Mitgliedern aufgeführt; und wenn sie später die Beiträge wieder aufnehmen, können sie jederzeit zum aktiven Status zurückkehren. Während sich jemand im inaktiven Status befindet, verliert er jedoch seine aktiven Privilegien wie Abstimmungsrecht oder Nominierung für das Steering Council sowie Commit-Zugriff.
Die anfänglichen aktiven Core-Team-Mitglieder werden alle umfassen, die derzeit im „Python core“-Team auf GitHub aufgeführt sind, und die anfänglichen inaktiven Mitglieder werden alle anderen umfassen, die in der Vergangenheit ein Committer waren.
Änderung dieses Dokuments
Änderungen an diesem Dokument erfordern mindestens eine Zweidrittelmehrheit der abgegebenen Stimmen in einer Abstimmung des Core-Teams.
TODO
- Viele Leute haben hilfreiche Vorschläge und Feedback gegeben; wir sollten prüfen, ob sie damit einverstanden sind, als Co-Autoren hinzugefügt zu werden.
- Es scheint, dass Aymeric Augustin die gesamte Django-Dokumentation geschrieben hat, also vermutlich das Urheberrecht besitzt; vielleicht sollten wir ihn fragen, ob er bereit ist, sie gemeinfrei zu geben, damit unsere Urheberrechtserklärung unten einfacher sein kann.
Danksagungen
Substanzieller Text wurde schamlos aus dem Governance-Dokument des Django-Projekts kopiert.
Urheberrecht
Text aus Django wurde unter ihrer Lizenz verwendet. Der Rest dieses Dokuments wurde gemeinfrei gestellt.
Quelle: https://github.com/python/peps/blob/main/peps/pep-8016.rst
Zuletzt geändert: 2025-02-01 08:55:40 GMT