Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 8015 – Organisation der Python-Community

Autor:
Victor Stinner
Status:
Abgelehnt
Typ:
Informational
Thema:
Governance
Erstellt:
04-Oct-2018
Inhaltsverzeichnis

Zusammenfassung

Diese PEP formalisiert die aktuelle Organisation der Python-Community und schlägt 3 Hauptänderungen vor

  • Formalisierung des bestehenden Konzepts von „Python-Teams“;
  • mehr Autonomie für Python-Teams;
  • Ersetzung des BDFL (Guido van Rossum) durch ein neues „Python Steering Committee“ aus 5 Mitgliedern mit begrenzten Rollen: im Grunde entscheiden, wie Entscheidungen getroffen werden, aber nicht Entscheidungen treffen.

PEPs werden von einem PEP-Delegierten oder durch eine Abstimmung (nur für Kernentwickler, >= 2/3 Mehrheit erforderlich) genehmigt.

Ablehnung der PEP

PEP 8015 wurde durch eine Abstimmung der Kernentwickler, die in PEP 8001 beschrieben ist, am Montag, dem 17. Dezember 2018, abgelehnt.

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

Begründung

Diese PEP beschreibt die Organisation der gesamten Python-Entwickler-Community, von den Python-Benutzern bis zum Python Steering Committee. Die Beschreibung aller Gruppen und aller Rollen in demselben Dokument trägt zu einer konsistenteren Organisation bei.

Die Anzahl der Governance-Änderungen wird minimiert, um einen reibungslosen Übergang von der alten BDFL-Organisation zur neuen Steering Committee-Organisation zu ermöglichen.

Ein wichtiges Designmerkmal der Organisation ist die Vermeidung von Entscheidungsengpässen. Diskussionen und Entscheidungen werden in Python-Teams verteilt, wo Experten für jedes Thema zu finden sind. Die Erwartung sind reibungslosere Diskussionen über PEPs: weniger Leute mit besserem Wissen über das Thema.

Zuvor wurden die meisten Entscheidungen vom Benevolent Dictator For Life (BDFL), Guido van Rossum, getroffen. Die wachsende Beliebtheit von Python erhöhte den Druck auf eine einzelne Person. Die vorgeschlagene Organisation verteilt Entscheidungen und Verantwortlichkeiten, um den Druck zu reduzieren und zu vermeiden, dass eine einzelne Person überfordert wird.

Um die meisten Entscheidungsbefugnisse in den Händen der Community zu belassen, hat das Python Steering Committee nur sehr begrenzte Rollen. Die Idee ist, das Risiko zu verringern, dass eine Gruppe von Personen oder Unternehmen das Python-Projekt durch nur wenige Einzelpersonen „übernimmt“. Das Projekt muss autonom und für jedermann offen bleiben.

Die sensibelsten PEPs werden per Demokratie entschieden: eine Abstimmung, die Kernentwicklern vorbehalten ist, siehe Abschnitt PEP-Prozess unten für die Abstimmungsmethode.

Allgemeine Richtlinien

  • Die Python-Community ist für alle offen.
  • Mitglieder müssen den Python Community Code of Conduct respektieren, der sicherstellt, dass Diskussionen konstruktiv bleiben und sich jeder willkommen fühlt.
  • Python ist und bleibt ein autonomes Projekt.
  • Entscheidungsträger sollten die Vielfalt seiner Benutzer und Beitragenden widerspiegeln.

Community-Organisation

Derzeit gibt es verschiedene Gruppen von Personen, die am Python-Projekt beteiligt sind. Je mehr Sie sich engagieren, desto mehr Entscheidungsbefugnis erhalten Sie. Es ist wichtig, dass die Personen, die in die tiefste Gruppe aufsteigen, die am meisten Vertrauenswürdigen sind.

Diese PEP formalisiert die folgenden Gruppen

  • Python-Benutzer
  • Python-Beitragende
  • Mitglieder von Python-Teams
  • Python-Kernentwickler
  • Mitglieder des Python Steering Committee
  • PSF Code of Conduct Arbeitsgruppe

Python-Benutzer

Dies ist die größte Gruppe: jeder, der Python benutzt.

Python-Beitragende

Sobald ein Python-Benutzer eine E-Mail an eine Python-Mailingliste sendet, sich über den Python-Bug-Tracker äußert, eine Python-Änderung vorschlägt oder überprüft, wird er zu einem Python-Beitragenden.

Python-Teams

Python ist zu groß geworden, um noch als einziges Team zu arbeiten; die Leute haben sich natürlich in Teams zusammengefunden, um enger an spezifischen Themen zu arbeiten, manchmal auch „Special Interest Group“ (SIG) genannt.

Wenn genügend Entwickler an einem bestimmten Thema interessiert sind, können sie ein neues Team gründen. Normalerweise besteht die Hauptaktion darin, den Python-Postmaster zu bitten, eine neue „SIG“-Mailingliste einzurichten, aber das Team kann sich entscheiden, einen anderen Kommunikationskanal zu nutzen.

Teammitglieder sind Python-Beitragende und Python-Kernentwickler. Das Team ist selbstorganisiert und verantwortlich dafür, auszuwählen, wer dem Team beitreten kann und wie.

Teammitglieder können die Bug-Triage-Berechtigung für die Bug-Tracker-Komponente des Teams erhalten. Je mehr Sie sich in einem Team engagieren, desto mehr Entscheidungsbefugnis und Verantwortung erhalten Sie.

Ein Team kann erlaubt werden, über eigene PEPs zu entscheiden, aber nur das Python Steering Committee kann dies genehmigen (und hat auch die Befugnis, dies zu widerrufen). Ein solcher Fall ist außergewöhnlich, derzeit hat ein einzelnes Team eine solche Berechtigung: das Packaging Team.

Siehe Anhang: Beispiele von Python-Teams.

Python-Kernentwickler

Eine eingeschränkte Definition eines Kernentwicklers ist die Fähigkeit, eine Änderung zusammenzuführen (irgendwo im Code) und die Bug-Triage-Berechtigung zu haben (für alle Bug-Tracker-Komponenten).

Kernentwickler sind Entwickler, die nachweislich über die erforderlichen Fähigkeiten verfügen, um zu entscheiden, ob eine Änderung genehmigt oder abgelehnt werden kann, aber auch (und das ist wichtiger) welche Änderungen nicht vorgenommen werden sollten. Python hat eine lange Geschichte, große Einschränkungen bei der Abwärtskompatibilität, hohe Qualitätsstandards (z. B. erfordern Änderungen neue Tests). Aus diesen Gründen kann es mehrere Monate oder länger dauern, bis man ein Kernentwickler wird.

Ein Kernentwickler zu werden bedeutet mehr Verantwortung. Wenn ein Entwickler beispielsweise eine Änderung zusammenführt, ist er für Rückschritte und die Wartung des geänderten Codes verantwortlich.

Von Kernentwicklern wird erwartet, dass sie im Hinblick auf den Verhaltenskodex vorbildlich sind. Sie werden ermutigt, Beitragende zu betreuen.

Befördern eines Beitragenden zum Kernentwickler

Sobald ein bestehender Kernentwickler der Meinung ist, dass ein Beitragender bereit ist, der Kerngruppe beizutreten und Kernentwickler zu werden, fragt dieser Kernentwickler den Beitragenden, ob er Kernentwickler werden möchte. Wenn der Beitragende an solchen neuen Verantwortlichkeiten interessiert ist, wird eine Abstimmung organisiert.

Die Abstimmung ist Kernentwicklern vorbehalten, ist öffentlich und dauert 1 Woche. Normalerweise beschreibt der Kernentwickler, der die Beförderung vorschlägt, die Arbeit und die Fähigkeiten des Kandidaten in der Beschreibung der Abstimmung. Ein Beitragender wird nur befördert, wenn zwei Drittel (>= 2/3) der Stimmen die Beförderung genehmigen („+1“). Nur „+1“- und „-1“-Stimmen werden gezählt; andere Stimmen (z. B. null, „-0“, „+0,5“) werden ignoriert.

Wenn der Kandidat befördert wird, erhält er normalerweise für 1 Monat einen Mentor, der ihm hilft, die neuen Verantwortlichkeiten zu übernehmen.

Wenn der Kandidat nicht befördert wird, kann später eine neue Abstimmung organisiert werden, wenn der Kandidat die fehlenden Fähigkeiten erworben hat, zum Beispiel 6 Monate später.

Python Steering Committee

Das Python Steering Committee besteht aus den vertrauenswürdigsten Kernentwicklern, da es die größte Entscheidungsbefugnis hat. Die Rollen dieser Gruppe sind streng begrenzt, um sicherzustellen, dass Python seine Autonomie behält und offen bleibt.

Das Python Steering Committee besteht aus 5 Mitgliedern. Sie werden für 3 Jahre gewählt und 1/3 wird jedes Jahr ersetzt (erstes Jahr: 1, zweites Jahr: 2, drittes Jahr: 2). Auf diese Weise bleibt ein Mitglied eine volle Python-Version lang im Amt und die Zusammensetzung des Komitees wird häufig aktualisiert. Ein Komiteemitglied kann sich für den Sitz bewerben, den es verlässt. Es gibt keine Amtszeitbeschränkungen.

Komiteemitglieder müssen Python-Kernentwickler sein. Es ist wichtig, dass die Mitglieder des Komitees die Vielfalt der Python-Benutzer und -Beitragenden widerspiegeln. Ein kleiner Schritt, um dies zu gewährleisten, ist die Durchsetzung, dass nur 2 Mitglieder (streng weniger als 50% der 5 Mitglieder) für denselben Arbeitgeber arbeiten können (demselben Unternehmen oder Tochtergesellschaften desselben Unternehmens).

Die Größe von 5 Mitgliedern wurde für die Vielfalt der Mitglieder und zur Sicherstellung gewählt, dass das Komitee weiterarbeiten kann, auch wenn ein Mitglied für einen unbekannten Zeitraum ausfällt.

Rollen des Python Steering Committee

Rollen des Python Steering Committee

  • Entscheiden, wie eine PEP genehmigt (oder abgelehnt oder vertagt) wird.
  • Berechtigungen für ein Python-Team gewähren oder entziehen. Zum Beispiel einem Team erlauben, die Bug-Triage-Berechtigung (für die Komponente des Teams) einem Beitragenden zu gewähren.

Um zu entscheiden, wie eine PEP genehmigt (oder abgelehnt oder vertagt) wird, gibt es zwei Optionen

  • Das Komitee wählt einen PEP-Delegierten (früher „BDFL-Delegate“ genannt): ein Kernentwickler, der die endgültige Entscheidung für die spezifische PEP treffen wird. Das Komitee wählt den PEP-Delegierten, der vom Python-Team, das die PEP diskutiert, vorgeschlagen werden kann.
  • Das Komitee kann eine Abstimmung über die PEP organisieren, siehe Abschnitt PEP-Prozess für die Abstimmungsorganisation. Das Komitee entscheidet, wann die Abstimmung organisiert wird. Eine Abstimmung wird für Änderungen bevorzugt, die alle Python-Benutzer betreffen, wie z. B. Sprachänderungen.

Das Komitee bewahrt die „Vision“ und Konsistenz von Python. Es stellt auch sicher, dass wichtige Funktionen abgeschlossen werden. Ihre Fähigkeit, PEP-Delegierte auszuwählen, soll ihnen helfen, dieses Ziel zu erreichen.

Wahl der Mitglieder des Python Steering Committee

Die Abstimmung wird vom Steering Committee organisiert. Sie wird 3 Wochen im Voraus angekündigt: Kandidaten müssen sich in dieser Zeit bewerben. Die Abstimmung ist Kernentwicklern vorbehalten und dauert 1 Woche. Um Selbstzensur zu vermeiden, verwendet die Abstimmung geheime Stimmzettel: vermeidet das Risiko von Feindseligkeit von jemandem, der mehr Macht erlangen könnte (wenn er gewählt wird).

Die Abstimmung verwendet die Schulze/Beatpath/CSSD-Variante der Condorcet-Methode unter Verwendung eines Online-Dienstes wie Condorcet Internet Voting Service (CIVS). Diese Abstimmungsmethode reduziert das Risiko von Gleichständen. Sie erzeugt auch eine Rangfolge aller Kandidaten, die für die Erstellung des Komitees erforderlich ist.

Im Falle eines Gleichstands wird sofort eine neue Abstimmung zwischen den am Gleichstand beteiligten Kandidaten mit derselben Abstimmungsmethode und ebenfalls für 1 Woche organisiert. Wenn die zweite Abstimmung erneut zu einem Gleichstand führt, ist das derzeitige Steering Committee für die Auswahl der gewählten Mitglieder verantwortlich.

Wenn ein Komiteemitglied zurücktritt, wird eine neue Abstimmung organisiert, um es zu ersetzen.

Wenn sich die Situation eines Komiteemitglieds so ändert, dass die Einschränkungen des Komitees nicht mehr erfüllt sind (z. B. es zieht zum selben Arbeitgeber wie zwei andere Komiteemitglieder um), muss es zurücktreten. Wenn der Arbeitgeber eines Mitglieds von dem Arbeitgeber von zwei anderen Mitgliedern übernommen wird, muss das Mitglied mit dem früher endenden Mandat zurücktreten, sobald die Übernahme abgeschlossen ist.

Wahl – Erstellung der Mitglieder des Python Steering Committee

Um den Prozess zu initialisieren, werden bei der Gründung des Komitees 5 Mitglieder gewählt. Die Abstimmung folgt denselben Regeln wie reguläre Komiteewahlen, mit der Ausnahme, dass die Wahl 5 Mitglieder benötigt und die Abstimmung vom PSF Board organisiert wird.

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.

Im Falle eines Gleichstands wird sofort eine zweite Abstimmung zwischen den am Gleichstand beteiligten Kandidaten und den nachfolgenden Kandidaten organisiert, um die verbleibenden Plätze zu besetzen. Die Abstimmung folgt denselben Regeln wie die reguläre Komiteewahl. Wenn die zweite Abstimmung immer noch zu einem Gleichstand führt, ist das PSF Board dafür verantwortlich, Mitglieder zu wählen und ihre Position im Abstimmungsergebnis zu bestimmen.

Die Reihenfolge im Abstimmungsergebnis muss für die gewählten Mitglieder eindeutig sein: #1 und #2 sind für 3 Jahre gewählt, #2 und #3 für 2 Jahre und #5 für 1 Jahr.

Beispiel für ein Abstimmungsergebnis mit Gleichstand

  • A
  • B
  • C
  • D
  • E, F
  • G
  • …

Die ersten 4 Kandidaten (A, B, C und D) werden sofort gewählt. Wenn E für denselben Arbeitgeber wie zwei andere gewählte Mitglieder arbeitet, wird F ebenfalls gewählt. Andernfalls wird eine zweite Abstimmung für den 5. Sitz zwischen E und F organisiert.

Sonderfall: Mitglieder des Steering Committee und PEPs

Ein Komiteemitglied kann ein PEP-Delegierter sein.

Ein Komiteemitglied kann eine PEP vorschlagen, darf aber nicht der PEP-Delegierte seiner eigenen PEP sein.

Wenn das Komitee entscheidet, dass über eine PEP abgestimmt werden muss, können Komiteemitglieder abstimmen, da sie auch Kernentwickler sind, aber sie haben keine höhere Befugnis als andere Kernentwickler.

PSF Code of Conduct Arbeitsgruppe

Charta

Der Zweck der Arbeitsgruppe ist die Förderung einer vielfältigen und inklusiven Python-Community durch die Durchsetzung des PSF-Verhaltenskodex sowie die Bereitstellung von Richtlinien und Empfehlungen für die Python-Community zu Verhaltenskodizes, die die Mission der PSF unterstützen, „die fortlaufende Entwicklung von Python-bezogener Technologie und Bildungsressourcen voranzutreiben“.

Wir arbeiten auf dieses gemeinsame Ziel in drei Bereichen hin

  • Überprüfung, Überarbeitung und Beratung von Richtlinien im Zusammenhang mit den PSF-Verhaltenskodizes und anderen von der PSF unterstützten Communities. Dies umfasst jede #python-Chat-Community und E-Mail-Liste auf python.org, die der PSF untersteht.
  • Erstellung eines standardmäßigen Satzes von Verhaltenskodizes und unterstützenden Dokumenten für verschiedene Interaktionskanäle wie, aber nicht beschränkt auf, Konferenzen, Mailinglisten, Slack/IRC, Code-Repositories und mehr.
  • Entwicklung von Schulungsmaterialien und anderen Prozessen zur Unterstützung von Python-Community-Organisatoren bei der Umsetzung und Durchsetzung des Verhaltenskodex.

Die Organisation dieser Arbeitsgruppe ist in der Charta der ConductWG definiert.

Sonderfall: Ausschluss eines Kernentwicklers

Wie jedes andere Mitglied der Python-Community kann die PSF Code of Conduct Arbeitsgruppe einen Kernentwickler für einen begrenzten Zeitraum ausschließen. In diesem Fall verliert der Kernentwickler sofort seinen Status als Kernentwickler. Von Kernentwicklern wird erwartet, dass sie im Hinblick auf den Verhaltenskodex vorbildlich sind.

Im Allgemeinen ist ein Ausschluss nur die letzte Option, wenn alle anderen Optionen ausgeschöpft wurden.

Am Ende des Ausschlusses darf der Entwickler wieder als regulärer Beitragender mitwirken.

Wenn der Entwickler sein Verhalten ändert, kann ein anderer Kernentwickler eine neue Abstimmung organisieren, um den Entwickler zur Beförderung zum Kernentwickler vorzuschlagen. Die Abstimmung folgt demselben Prozess wie für jeden anderen Python-Beitragenden.

PEP-Prozess

Es gibt 2 Hauptrollen bei PEPs

  • PEP-Autoren
  • PEP-Delegierter

PEP-Autoren tun ihr Bestes, um qualitativ hochwertige PEPs zu schreiben.

Der PEP-Delegierte ist dafür verantwortlich, die Autoren bei der Verbesserung ihrer PEPs zu unterstützen und ist diejenige, die die endgültige Entscheidung trifft (Annahme, Ablehnung oder Vertagung der PEP). Sie können auch helfen, die Diskussion zu leiten.

Wenn keine Entscheidung getroffen wird, können die Autoren die PEP später erneut vorschlagen (z. B. ein Jahr später), möglichst mit neuen Daten zur Begründung der Änderung. Ein PEP-Delegierter kann eine PEP auch als „Deferred“ (vertagt) markieren, um die PEP nicht abzulehnen und die Diskussion später wieder aufzunehmen.

PEPs, die spezifisch für ein Python-Team sind, werden auf der Mailingliste des Teams diskutiert. PEPs, die alle Python-Entwickler betreffen (wie z. B. Sprachänderungen), müssen auf der Mailingliste python-dev diskutiert werden.

Abstimmung über eine PEP

Wenn das Python Steering Committee entscheidet, dass eine PEP eine breitere Zustimmung benötigt, wird eine Abstimmung organisiert.

Die Abstimmung ist Kernentwicklern vorbehalten, ist öffentlich, wird 1 Woche im Voraus angekündigt und dauert 1 Woche. Die PEP kann während der 1-wöchigen Ankündigungsfrist noch aktualisiert werden, darf aber während der Abstimmung nicht geändert werden. Eine solche Abstimmung findet auf der Mailingliste statt, auf der die PEP diskutiert wurde. Das Komitee entscheidet, wann die Abstimmung organisiert wird. Die PEP muss eine angemessene Zeit lang diskutiert worden sein, bevor sie zur Abstimmung gestellt wird.

Eine PEP wird nur genehmigt, wenn zwei Drittel (>= 2/3) der Stimmen die PEP genehmigen („+1“). Nur „+1“- und „-1“-Stimmen werden gezählt; andere Stimmen (z. B. null, „-0“, „+0,5“) werden ignoriert.

Eine PEP kann nur durch eine Abstimmung genehmigt oder abgelehnt werden, nicht vertagt werden.

Mangel an Entscheidungen

Wenn eine Diskussion keinen Konsens erreicht, wenn das Python Steering Committee keinen PEP-Delegierten wählen kann oder wenn ein PEP-Delegierter keine Entscheidung treffen kann, besteht das offensichtliche Risiko, dass Python sich nicht weiterentwickelt.

Das ist in Ordnung. Manchmal ist Nichtstun die klügste Wahl.

Ändern dieser PEP

Die erste Version dieser PEP wurde nach der Entscheidung von Guido van Rossum im Juli 2018, seine Rolle als BDFL niederzulegen, verfasst. Vor dieser PEP waren die Rollen von Mitgliedern der Python-Community nie formalisiert. Es ist schwierig, beim ersten Versuch eine perfekte Organisation zu entwerfen. Diese PEP kann in Zukunft aktualisiert werden, um die Organisation anzupassen, den Umgang mit Grenzfall-Situationen zu spezifizieren und Fehler zu beheben.

Jede Änderung dieser PEP muss durch eine Abstimmung validiert werden. Die Abstimmung wird 3 Wochen im Voraus angekündigt, ist Kernentwicklern vorbehalten, findet öffentlich auf der Mailingliste python-committers statt und dauert 1 Woche. Die vorgeschlagene PEP-Änderung kann während der 3-wöchigen Ankündigungsfrist noch aktualisiert werden, darf aber während der Abstimmung nicht geändert werden.

Die Änderung wird nur genehmigt, wenn vier Fünftel (>= 4/5) der Stimmen die Änderung genehmigen („+1“). Nur „+1“- und „-1“-Stimmen werden gezählt; andere Stimmen (z. B. null, „-0“, „+0,5“) werden ignoriert.

Anhang: Zusammenfassung der Abstimmungen

Abstimmung Ankündigung Offen Stimmzettel Methode
Beförderung eines Beitragenden keine 1 Woche öffentlich >= 2/3 Mehrheit
PEP 1 Woche 1 Woche öffentlich >= 2/3 Mehrheit
Ändern dieser PEP 3 Wochen 1 Woche öffentlich >= 4/5 Mehrheit
Steering Committee 3 Wochen 1 Woche privat Condorcet (Schulze/Beatpath/CSSD)

Alle diese Abstimmungen sind Kernentwicklern vorbehalten.

Anhang: Beispiele von Python-Teams

Nachfolgend finden Sie Beispiele einiger Python-Teams (die Liste wird in dieser PEP nicht aktuell gehalten).

Packaging Team

Das Packaging-Team verwaltet seine eigene PEP-Kategorie und kann seine eigenen PEPs genehmigen (oder ablehnen).

  • Website: packaging.python.org
  • Mailingliste: distutils-sig
  • Bug-Tracker-Komponente: Distutils
  • Beispielmitglieder: Paul Moore, Alyssa Coghlan, Donald Stuff
  • Standardbibliotheksmodul: distutils
  • Aktueller PEP-Delegierter: Paul Moore

IDLE Team

IDLE ist ein Sonderfall in der Python-Standardbibliothek: es ist eine ganze Anwendung, nicht nur ein Modul. Aus diesem Grund wurde entschieden, dass der Code in allen stabilen Python-Zweigen derselbe sein wird (während die Standardbibliothek in neueren stabilen Zweigen abweicht).

  • Bug-Tracker-Komponente: IDLE
  • Beispielmitglieder: Terry Reedy, Cheryl Sabella, Serhiy Storchaka
  • Standardbibliotheksmodul: idlelib

Mentorship Team

Ein Kernentwickler zu werden ist ein langer und langsamer Prozess. Mentoring ist eine effiziente Methode, um Beitragende zu zukünftigen Kernentwicklern auszubilden und eine Vertrauensbeziehung aufzubauen.

Hinweis: Die Gruppe ist nicht für die Beförderung von Kernentwicklern zuständig.

Documentation Team

  • Mailingliste: doc-sig
  • Bug-Tracker-Komponente: Documentation
  • GitHub-Tag: type-doc
  • Beispielmitglieder: Julien Palard, INADA Naoki, Raymond Hettinger.

Das Team verwaltet auch Dokumentationsübersetzungen.

Siehe auch das Mentorship Team, das das „Devguide“ pflegt.

Security Team

  • Website: https://pythonlang.de/news/security/
  • Mailinglisten
    • security@python.org (zur Meldung von Schwachstellen)
    • security-sig (öffentliche Liste)
  • Standardbibliotheksmodule: hashlib, secrets und ssl
  • Beispielmitglieder: Christian Heimes, Benjamin Peterson

Die Mailingliste security@python.org ist nur auf Einladung zugänglich: nur Mitglieder des „Python Security Response Team“ (PSRT) können E-Mails lesen und antworten; während security-sig öffentlich ist.

Hinweis: Dieses Team schlägt selten PEPs vor.

Performance Team

In der Regel betreffen PEPs, die die Leistung beeinträchtigen, jeden und werden daher eher auf der Mailingliste python-dev als auf der Mailingliste speed diskutiert.

Asynchronous Programming Team

PEPs, die nur asyncio und contextvars ändern, können auf der Mailingliste async-sig diskutiert werden, während Änderungen, die die Python-Sprache betreffen, auf python-dev diskutiert werden müssen.

Type Hints Team

Hinweis: Es gibt ein Backport für Python 3.6 und älter, siehe typing auf PyPI.

Versionshistorie

Verlauf dieser PEP

  • Version 7: Anpassung des Steering Committee
    • Das Steering Committee besteht nun aus 5 Personen statt aus 3.
    • Es gibt keine Amtszeitbeschränkungen (anstelle einer Beschränkung auf 2 Mandate: insgesamt 6 Jahre).
    • Ein Komiteemitglied kann nun ein PEP-Delegierter sein.
  • Version 6: Anpassung der Abstimmungen
    • Spezifizierung der Condorcet-Methode: Verwendung der Schulze/Beatpath/CSSD-Variante zur Wahl der Mitglieder des Python Steering Committee. Spezifizierung des Umgangs mit Gleichständen und der Einschränkung bezüglich der Arbeitgeber.
    • Abstimmungen zur Beförderung eines Beitragenden und zu PEPs erfordern nun >= 2/3 statt 50%+1.
    • Abstimmungen zur Änderung dieser PEP erfordern nun >= 4/5 statt 50%+1.
    • Erläuterung des Umgangs mit einer Firmenübernahme.
  • Version 5: Wahl der Mitglieder des Python Steering Committee mit geheimen Stimmzetteln
  • Version 4
    • Anpassung der Abstimmungen: 1 Woche statt 1 Monat geöffnet und im Voraus angekündigt.
    • Umbenennung des „Python Core Board“ in „Python Steering Committee“;
    • Klarstellung, dass dieses Komitee keine PEPs genehmigt und dass Komiteemitglieder nicht mehr als 2 Mandate anhäufen können;
    • Hinzufügen des „Type Hints“-Teams zum Anhang.
  • Version 3: Hinzufügen der Abschnitte „Sonderfall: Ausschluss eines Kernentwicklers“ und „Wie man diese PEP aktualisiert“.
  • Version 2: Umbenennung des „Python Board“ in „Python Core Board“, um Verwechslungen mit dem PSF Board zu vermeiden.
  • Version 1: Erste Version, veröffentlicht auf python-committers und discuss.python.org.

Quelle: https://github.com/python/peps/blob/main/peps/pep-8015.rst

Zuletzt geändert: 2025-02-01 08:55:40 GMT