Scikit-learn Governance und Entscheidungsfindung#

Der Zweck dieses Dokuments ist die Formalisierung des Governance-Prozesses, der vom scikit-learn-Projekt verwendet wird, um zu klären, wie Entscheidungen getroffen werden und wie die verschiedenen Elemente unserer Community interagieren. Dieses Dokument etabliert eine Entscheidungsfindungsstruktur, die das Feedback aller Mitglieder der Community berücksichtigt und bestrebt ist, einen Konsens zu finden und gleichzeitig Blockaden zu vermeiden.

Dies ist ein meritokratisches, konsensbasiertes Community-Projekt. Jeder, der Interesse am Projekt hat, kann der Community beitreten, zum Projektentwurf beitragen und am Entscheidungsprozess teilnehmen. Dieses Dokument beschreibt, wie diese Teilnahme stattfindet und wie man sich innerhalb der Projekt-Community Verdienste erwirbt.

Rollen und Verantwortlichkeiten#

Wir unterscheiden zwischen Beitragsleistenden (Contributors), Kernbeitragsleistenden (Core Contributors) und dem Technischen Komitee (Technical Committee). Ein wesentlicher Unterschied zwischen ihnen sind ihre Stimmrechte: Beitragsleistende haben keine Stimmrechte, während die beiden anderen Gruppen alle Stimmrechte haben, sowie die Berechtigungen für die für ihre Rollen relevanten Werkzeuge.

Beitragsleistende (Contributors)#

Beitragsleistende sind Community-Mitglieder, die auf konkrete Weise zum Projekt beitragen. Jeder kann ein Beitragsleistender werden, und Beiträge können viele Formen annehmen – nicht nur Code –, wie im Leitfaden für Beitragsleistende beschrieben. Es gibt keinen Prozess, um ein Beitragsleistender zu werden: Sobald jemand auf irgendeine Weise zum Projekt beiträgt, ist er ein Beitragsleistender.

Kernbeitragsleistende (Core Contributors)#

Alle Kernbeitragsleistenden-Mitglieder haben die gleichen Stimmrechte und das Recht, neue Mitglieder für alle unten aufgeführten Rollen vorzuschlagen. Ihre Mitgliedschaft wird als Organisationsmitgliedschaft in der scikit-learn GitHub Organisation repräsentiert.

Sie sind außerdem herzlich eingeladen, an unseren monatlichen Kernbeitragsleistenden-Treffen teilzunehmen.

Neue Mitglieder können von jedem bestehenden Mitglied nominiert werden. Sobald sie nominiert wurden, findet eine Abstimmung durch die aktuellen Kernbeitragsleistenden statt. Die Abstimmung über neue Mitglieder ist eine der wenigen Aktivitäten, die auf der privaten Mailingliste des Projekts stattfinden. Obwohl erwartet wird, dass die meisten Abstimmungen einstimmig ausfallen, reichen zwei Drittel der abgegebenen Stimmen aus. Die Abstimmung muss mindestens 1 Woche offen sein.

Kernbeitragsleistende, die in den letzten 12 Monaten nicht entsprechend ihrer Rolle zum Projekt beigetragen haben, werden gefragt, ob sie als Emeritus-Mitglieder tätig werden und ihre Rechte zurückgeben möchten, bis sie wieder aktiv werden. Die Liste der Mitglieder, aktiv und emeritus (mit Daten, wann sie aktiv wurden), ist öffentlich auf der scikit-learn-Website. Es liegt in der Verantwortung der aktiven Kernbeitragsleistenden, eine solche jährliche Erinnerungs-E-Mail zu versenden.

Die folgenden Teams bilden die Gruppe der Kernbeitragsleistenden

  • Team für die Erfahrung von Beitragsleistenden (Contributor Experience Team) Das Team für die Erfahrung von Beitragsleistenden verbessert die Erfahrung der Beitragsleistenden, indem es bei der Triage von Issues und Pull Requests hilft, wiederkehrende Muster erkennt, bei denen Personen möglicherweise Schwierigkeiten haben, und diese Aspekte des Projekts verbessert.

    Zu diesem Zweck verfügen sie über die erforderlichen Berechtigungen auf GitHub, um Issues zu labeln und zu schließen. Ihre Arbeit ist entscheidend für die Verbesserung der Kommunikation im Projekt und die Begrenzung der Überfüllung des Issue Trackers.

  • Kommunikationsteam (Communication Team) Mitglieder des Kommunikationsteams helfen bei der Öffentlichkeitsarbeit und Kommunikation für scikit-learn. Ziel des Teams ist es, das öffentliche Bewusstsein für scikit-learn, seine Funktionen und Nutzung sowie für das Branding zu entwickeln.

    Dazu können sie die scikit-learn-Konten in verschiedenen sozialen Netzwerken verwalten und Materialien erstellen. Sie verfügen auch über die erforderlichen Rechte für unser Blog-Repository und andere relevante Konten und Plattformen.

  • Dokumentationsteam (Documentation Team) Mitglieder des Dokumentationsteams beschäftigen sich unter anderem mit der Dokumentation des Projekts. Sie können auch in andere Aspekte des Projekts eingebunden sein, aber ihre Überprüfungen von Dokumentationsbeiträgen gelten als maßgeblich und sie können solche Beiträge zusammenführen.

    Zu diesem Zweck verfügen sie über Berechtigungen, um Pull Requests im Repository von scikit-learn zusammenzuführen.

  • Wartungsteam (Maintainers Team) Wartende sind Community-Mitglieder, die durch kontinuierliches Engagement in der Community gezeigt haben, dass sie sich der Weiterentwicklung des Projekts widmen. Sie haben gezeigt, dass man ihnen vertrauen kann, scikit-learn sorgfältig zu warten. Wartende zu sein ermöglicht es Beitragsleistenden, ihre projektbezogenen Aktivitäten einfacher fortzusetzen, indem sie direkten Zugriff auf das Repository des Projekts erhalten. Von Wartenden wird erwartet, dass sie Codebeiträge überprüfen, genehmigte Pull Requests zusammenführen, für und gegen das Zusammenführen eines Pull Requests abstimmen und an der Entscheidung über wesentliche API-Änderungen beteiligt sind.

Technisches Komitee (Technical Committee)#

Die Mitglieder des Technischen Komitees (TC) sind Wartende mit zusätzlichen Verantwortlichkeiten, um den reibungslosen Ablauf des Projekts zu gewährleisten. Von TC-Mitgliedern wird erwartet, dass sie an der strategischen Planung teilnehmen und Änderungen am Governance-Modell genehmigen. Zweck des TC ist es, einen reibungslosen Fortschritt aus der Perspektive des Gesamtbildes zu gewährleisten. Tatsächlich erfordern Änderungen, die das gesamte Projekt betreffen, eine synthetische Analyse und einen Konsens, der sowohl explizit als auch informiert ist. In Fällen, in denen die Kernbeitragsleistenden-Community (einschließlich der TC-Mitglieder) innerhalb des erforderlichen Zeitrahmens keinen solchen Konsens erzielen kann, ist das TC die Instanz, die das Problem löst. Die Mitgliedschaft im TC erfolgt durch Nominierung durch einen Kernbeitragsleistenden. Eine Nominierung führt zu einer Diskussion, die nicht länger als einen Monat dauern darf, und dann zu einer Abstimmung durch die Kernbeitragsleistenden, die eine Woche lang offen bleibt. TC-Mitgliedschaftsabstimmungen unterliegen einer Zwei-Drittel-Mehrheit aller abgegebenen Stimmen sowie einer einfachen Mehrheit aller aktuellen TC-Mitglieder. Von TC-Mitgliedern, die sich nicht aktiv an den TC-Aufgaben beteiligen, wird erwartet, dass sie zurücktreten.

Das Technische Komitee von scikit-learn besteht aus Thomas Fan, Alexandre Gramfort, Olivier Grisel, Adrin Jalali, Andreas Müller, Joel Nothman und Gaël Varoquaux.

Entscheidungsfindungs-Prozess#

Entscheidungen über die Zukunft des Projekts werden durch Diskussion mit allen Mitgliedern der Community getroffen. Alle nicht-sensiblen Projektmanagement-Diskussionen finden auf der Mailingliste der Projekt-Beitragsleistenden und dem Issue Tracker statt. Gelegentlich finden sensible Diskussionen auf einer privaten Liste statt.

Scikit-learn verwendet einen "konsensorientierten" Prozess zur Entscheidungsfindung. Die Gruppe versucht, eine Lösung zu finden, die keine offenen Einwände von Kernbeitragsleistenden hat. Zu jedem Zeitpunkt während der Diskussion kann ein Kernbeitragsleistender eine Abstimmung einleiten, die einen Monat nach der Einleitung der Abstimmung endet. Die meisten Abstimmungen müssen durch einen SLEP gestützt werden. Wenn keine Option zwei Drittel der abgegebenen Stimmen erhält, wird die Entscheidung an das TC eskaliert, das wiederum einen konsensorientierten Prozess mit der Fallback-Option einer einfachen Mehrheitswahl verwendet, wenn innerhalb eines Monats kein Konsens gefunden werden kann. Dies bezeichnen wir im Folgenden als "den Entscheidungsfindungs-Prozess".

Entscheidungen (zusätzlich zur Aufnahme von Kernbeitragsleistenden und TC-Mitgliedschaft wie oben) werden gemäß den folgenden Regeln getroffen:

  • Kleine Code- und Dokumentationsänderungen, wie z.B. kleine Wartungsänderungen ohne Änderung der Codemärtyrium, Korrektur von Tippfehlern oder Hinzufügen/Korrektur eines Satzes, aber keine Änderung der Landing Page von scikit-learn.org oder der "Über uns"-Seite: Erfordert ein +1 von einem Kernbeitragsleistenden, kein -1 von einem Kernbeitragsleistenden (Lazy Consensus), findet auf der Issue- oder Pull-Request-Seite statt. Von Kernbeitragsleistenden wird erwartet, dass sie anderen "angemessene Zeit" geben, ihre Meinung zu dem Pull Request abzugeben, wenn sie sich nicht sicher sind, ob andere zustimmen würden.

  • Codeänderungen und größere Dokumentationsänderungen erfordern ein +1 von zwei Kernbeitragsleistenden, kein -1 von einem Kernbeitragsleistenden (Lazy Consensus), findet auf der Issue- oder Pull-Request-Seite statt.

  • Änderungen der API-Prinzipien und Änderungen von Abhängigkeiten oder unterstützten Versionen folgen dem oben beschriebenen Entscheidungsprozess. Insbesondere werden Änderungen der API-Prinzipien durch Enhancement Proposals (SLEPs) unterstützt. Kleinere Entscheidungen wie unterstützte Versionen können auf einem GitHub Issue oder Pull Request erfolgen.

  • Änderungen am Governance-Modell folgen dem Prozess, der in SLEP020 beschrieben ist.

Wenn ein Veto (-1 Stimme) bei einem Lazy Consensus abgegeben wird, kann der Antragsteller die Community und die Wartenden anrufen und die Änderung kann mit dem oben beschriebenen Entscheidungsverfahren genehmigt oder abgelehnt werden.

Änderungen am Governance-Modell#

Änderungen am Governance-Modell erfolgen durch einen Enhancement Proposal oder einen GitHub Pull Request. Ein Enhancement Proposal durchläuft den "Entscheidungsfindungs-Prozess", der im vorherigen Abschnitt beschrieben ist. Alternativ kann ein Autor eine Änderung direkt am Governance-Modell mit einem GitHub Pull Request vorschlagen. Logistisch kann ein Autor einen Entwurf-Pull-Request für Feedback öffnen und anschließend einen neuen, überarbeiteten Pull-Request zur Abstimmung einreichen. Sobald der Autor mit dem Zustand des Pull Requests zufrieden ist, kann er auf der öffentlichen Mailingliste zur Abstimmung aufrufen. Während der einmonatigen Abstimmungsperiode darf der Pull Request nicht geändert werden. Eine Pull Request-Genehmigung zählt als positive Stimme, und eine "Änderungen anfordern"-Bewertung zählt als negative Stimme. Wenn zwei Drittel der abgegebenen Stimmen positiv sind, wird die Änderung des Governance-Modells akzeptiert.

Enhancement Proposals (SLEPs)#

Für alle Abstimmungen muss ein Vorschlag öffentlich gemacht und vor der Abstimmung diskutiert worden sein. Ein solcher Vorschlag muss ein konsolidiertes Dokument in Form eines "Scikit-Learn Enhancement Proposal" (SLEP) sein und keine lange Diskussion über ein Issue. Ein SLEP muss als Pull-Request an die Enhancement Proposals unter Verwendung der SLEP-Vorlage eingereicht werden. SLEP000 beschreibt den Prozess detaillierter.