Projektwahl

Es gibt viele Open-Source-Projekte, aber es wird am fruchtbarsten sein, diejenigen zu untersuchen, die CPython in einigen wichtigen Kennzahlen ausreichend ähnlich sind

1. die Anzahl der Mitwirkenden und ihre Aktivität (es gibt Skalierungsprobleme, die die Governance-Modelle sehr kleiner Projekte für unsere Zwecke nicht sehr aufschlussreich machen);
2. weitgehend oder teilweise Community-gesteuert zu sein (von Unternehmen gesteuerte Projekte können sich andere Governance-Optionen leisten, da die Unternehmenshierarchie Macht über die Hauptteilnehmer hat);
3. mit wichtigen Designentscheidungen konfrontiert zu sein, die einen etwas formellen Entscheidungsprozess erfordern.

Schlüsselpersonen und ihre Funktionen

Im Rust-Projekt gibt es Teams, die für bestimmte Bereiche verantwortlich sind. Für Sprachfunktionen gibt es ein „Lang-Team“, für Tools gibt es „Dev Tools“ und „Cargo“ und so weiter. Umstrittene Themen haben Moderatoren, die die Diskussion leiten und oft nicht die Entscheidungsträger sind. Typischerweise sind die Moderatoren die Autoren der vorgeschlagenen Änderungen (siehe „Kontroverser Entscheidungsprozess“ unten). Sie stellen sicher, dass alle wichtigen Entscheidungsträger zusammen mit interessierten Community-Mitgliedern eingebunden sind. Sie treiben durch Iteration auf ein einvernehmliches Ergebnis hin.

In der Praxis bedeutet dies, dass Entscheidungen selten an das Kernteam eskaliert werden.

Die häufigste Rolle eines Mitwirkenden ist die Teamzugehörigkeit. Berechtigungen für die Triage von Issues/Code-Reviews ohne Teamzugehörigkeit sind selten. Mitwirkende haben vollen Commit-Zugriff, die Trennung der Code-Verantwortung basiert auf Vertrauen. Das Schreiben in das Compiler-Repository wird missbilligt, alle Änderungen erfolgen über Pull-Requests und werden nach Prüfung und Genehmigung von einem Integrationsbot zusammengeführt.

Neue Teammitglieder werden auf Vorschlag eines bestehenden Teammitglieds hinzugefügt.

Regelmäßiger Entscheidungsprozess

Die Hauptarbeit erfolgt über GitHub Issues und Pull-Requests. Die Genehmigung eines Pull-Requests durch ein beliebiges Teammitglied erlaubt dessen Zusammenführung ohne weiteren Prozess. Alle zusammengeführten Pull-Requests landen in der nächsten stabilen Version von Rust.

Die Benachrichtigung relevanter Personen durch Erwähnungen ist wichtig. Das Abhören des Feuerwehrautos von E-Mails für alle GitHub-Aktivitäten ist nicht beliebt.

Es gibt öffentliche Planungs- und Triage-Meetings, die auf IRC und Discord stattfinden. Sie sind nicht sehr beliebt, da die meiste Arbeit über GitHub erledigt wird. Diskussionen finden auch auf offiziellen Rust-Foren (https://users.rust-lang.org/ und https://internals.rust-lang.org/) statt. Ein dediziertes Moderationsteam ist für die Protokollführung und die Durchsetzung des Verhaltenskodex verantwortlich.

Kontroverser Entscheidungsprozess

Größere oder kontroverse Arbeiten durchlaufen einen RFC-Prozess. Er ermöglicht es jedem, seine Gedanken zu äußern und iterativ zu einer Lösung zu gelangen. Irgendwann, wenn alle blockierenden Bedenken relevanter Teammitglieder ausgeräumt sind, signieren sie die RFC und sie erreicht eine „Final Comment Period“. Dies erfordert keinen Konsens aller Teilnehmer, vielmehr sollte kein starker Konsens gegen den Vorschlag bestehen.

Nach 10 Tagen wird die RFC **zusammengeführt**, es sei denn, es werden neue blockierende Bedenken von Teammitgliedern geäußert. Eine „Zusammenführung“ bedeutet, dass die Arbeit an der Implementierung des Features und dessen Integration nun ungehindert erfolgen kann. Eine RFC muss keine Referenzimplementierung haben, um akzeptiert zu werden.

Die anderen möglichen Ergebnisse der „Final Comment Period“ sind:

• die RFC zu **verschieben** (ähnlich dem Status „Deferred“ in PEPs),
• sie **wieder in die Diskussion zu bringen**, wenn blockierende Bedenken ausgeräumt werden können, oder
• sie zu **schließen**, wenn blockierende Bedenken nicht lösbar sind. Wenn eine RFC als **geschlossen** markiert wird, gibt es eine 7-tägige Gnadenfrist, um zu debattieren, ob sie geschlossen werden sollte.

In der Praxis werden Bedenken gegen eine RFC anfangs sehr oft geäußert, führen aber selten dazu, dass die RFC vollständig verworfen wird.

Dieser Prozess skaliert gut für Änderungen mit geringen Konflikten und/oder kleinere Änderungen. Bei den größten kontroversen Änderungen wird die Diskussion unübersichtlich. Dies ist ein Thema, das derzeit (Stand August 2018) die Rust-Teams beschäftigt (siehe: „Listening and Trust, part 1“, „Listening and Trust, part 2“, „Listening and Trust, part 3“, „Proposal for a staged RFC process“).

Planung einer neuen Veröffentlichung

Alle sechs Wochen wird der Rust-Compiler mit dem veröffentlicht, was er zu diesem Zeitpunkt enthielt. Es gibt noch keine LTS-Kanäle oder -Releases, aber dieses Konzept ist geplant, um die Weiterverteiler in die Lage zu versetzen, mit der Entwicklung besser Schritt zu halten.

Alle paar Jahre wird eine sogenannte „Edition“ veröffentlicht. Dies sind Meilenstein-Releases mit vollständigen Sätzen aktualisierter Dokumentation und Tools. Sie können zu früheren Editionen abwärtskompatibel sein. Externe Pakete optieren für Breaking Changes in ihren Crate-Metadaten. Der Rust-Compiler unterstützt alle Editionen, die vor seiner Veröffentlichung existierten. Verknüpfungen zwischen Crates verschiedener unterstützter Editionen sind möglich.

Änderungen im Prozess im Laufe der Zeit

Die Programmiersprache Rust wurde von Graydon Hoare ins Leben gerufen, der sie einige Jahre lang als persönliches Projekt entwickelte. Als Mozilla begann, das Projekt zu sponsern, wuchs das Team langsam mit Graydon als BDFL-ähnlicher Figur. Er verließ das Projekt 2013. Rust funktioniert seitdem ohne BDFL. Der RFC-Prozess wurde später eingeführt. Anfangs fanden einige Design-Diskussionen während wöchentlicher Video-Meetings unter Ausschluss der Öffentlichkeit statt, die im Mai 2015 (vor der Veröffentlichung von Rust 1.0) eingestellt wurde und organisch durch offene Diskussionen und direkten Einfluss von Teams ersetzt wurde.

Die Anzahl der Teams wächst im Laufe der Zeit. Die Anzahl der vom Kernteam getroffenen technischen Entscheidungen nimmt ab, stattdessen werden diese an die jeweiligen Teams delegiert.

Das Konzept einer „Final Comment Period“ wurde eingeführt, um mehr öffentliche Diskussionen zu fördern und auf eine unmittelbar bevorstehende Änderung reagieren zu können, anstatt eine überhastete Entscheidung rückgängig machen zu müssen, die bereits getroffen wurde.

Schlüsselpersonen und ihre Funktionen

Die OpenStack-Community besteht aus vielen verschiedenen Projektteams, die für die Erstellung verschiedener Softwarekomponenten (Block-Storage-Management, Compute-Management usw.) oder die Verwaltung verschiedener Teile der von der Community befolgten Prozesse (z. B. die Verfolgung des Release-Zeitplans) verantwortlich sind. Jedes Team wird von einem **Projektteamleiter (PTL)** geleitet, der von den **aktiven Projektmitwirkenden (APCs)** für dieses Projekt gewählt wird.

Aktive Projektmitwirkende (APCs) sind aktuelle Mitwirkende eines bestimmten Projektteams. Der APC-Status erfordert formell zwei Dinge: die Mitgliedschaft als Einzelperson in der OpenStack Foundation (die Mitgliedschaft ist kostenlos) und eine innerhalb des letzten Jahres (zwei Entwicklungszyklen) in einem von einem Projektteam verwalteten Repository zusammengeführte Änderung.

Der gewählte PTL dient einer Amtszeit, die einem Entwicklungszyklus entspricht (ungefähr 6 Monate). Es gibt keine Begrenzung für die Anzahl aufeinanderfolgender Amtszeiten, die eine Person als PTL dienen kann, und es ist üblich, dass jemand mehrere Amtszeiten hintereinander dient. Es ist auch nicht ungewöhnlich, dass ein Team nur einen Kandidaten hat, der sich für die Rolle des PTL für einen bestimmten Zyklus meldet, in welchem Fall keine Wahl erforderlich ist.

Der PTL vertritt das Team in allen Fällen, außer wenn er bestimmte Verantwortlichkeiten ausdrücklich delegiert hat. Zum Beispiel benennen viele Teams einen separaten **Release Liaison**, um den Release-Prozess für einen Entwicklungszyklus zu verwalten. Der PTL dient auch als endgültiger Entscheidungsträger in Fällen, in denen zwischen den Teammitgliedern kein Konsens erzielt werden kann.

Während alle APCs den PTL eines Teams wählen, wird in vielen anderen Fällen nur das **Kernprüfer-Team** zu politischen Entscheidungen für das Team konsultiert. Jeder kann jeden Patch für jedes OpenStack-Projekt überprüfen. Nachdem jemand nachgewiesen hat, dass er ein gutes Verständnis der technischen Probleme eines Projekts hat, nützliches Feedback zu Überprüfungen gibt und die Richtung des Projekts versteht, kann er eingeladen werden, Mitglied des Kernprüfungsteams zu werden. Im Gegensatz zu vielen anderen Communities gewährt ihm dieser Status nicht das Recht, Code ohne Überprüfung einzureichen. Stattdessen wird er gebeten, sich zur Überprüfung von Code anderer Mitwirkender zu verpflichten und an Diskussionen über Teamentscheidungen teilzunehmen. Die Aufforderung, Mitglied des Kernprüfungsteams zu werden, ist ein starkes Zeichen des Vertrauens.

Das Technical Committee (TC) ist für die Verwaltung der Entwicklung von OpenStack als Ganzes verantwortlich. Die 13 Mitglieder des Technical Committee werden direkt von den APCs aller Projektteams gewählt. Jedes Mitglied dient einer Amtszeit von zwei Entwicklungszyklen (ungefähr 1 Jahr), wobei die Wahlen so aufgeteilt sind, dass nur etwa die Hälfte der Amtszeiten der Mitglieder zu einem bestimmten Zeitpunkt abläuft, um Kontinuität zu gewährleisten. Das TC legt allgemeine Richtlinien fest, wie z. B. die Kriterien für die Aufnahme neuer Projektteams, die Richtlinie zur Verwerfung von Python 2, Testanforderungen usw.

Regelmäßiger Entscheidungsprozess

Alle Wahlen für PTL- oder TC-Mitglieder nutzen https://civs.cs.cornell.edu zur Durchführung einer **Condorcet-Wahl**. Dieses System wurde gewählt, weil es Konsenskandidaten gegenüber reiner Popularität betont.

Die OpenStack-Mitwirkenden-Community nutzt 3 primäre Werkzeuge für Diskussionen: die openstack-dev Mailingliste, eine Gerrit-Code-Review-Instanz unter https://review.openstack.org und eine Reihe von OpenStack-spezifischen IRC-Kanälen auf Freenode. Es gibt einige Teams, deren Mitwirkende hauptsächlich in China ansässig sind und die Schwierigkeiten haben, auf IRC zuzugreifen. Diese Teams nutzen stattdessen alternative Plattformen wie WeChat.

Das für die Diskussion einer bestimmten Entscheidung verwendete Werkzeug variiert je nach Gewicht und Auswirkung. Jeder wird ermutigt, entweder die Mailingliste oder Gerrit für asynchrone Diskussionen über einen breiteren Zeitzonenbereich und Firewalls hinweg zu nutzen, insbesondere zur Veröffentlichung endgültiger Entscheidungen für den Rest der Community.

Politische Entscheidungen, die auf ein einzelnes Team beschränkt sind, werden normalerweise vom Kernprüfungsteam eines Projekts getroffen, und die politischen Entscheidungen und Entscheidungsprozesse können zwischen den Teams variieren. Einige Gruppen schreiben ihre Teamrichtlinien in ihrem Dokumentationsrepository auf und nutzen das Code-Review-Tool (Gerrit), um darüber abzustimmen. Einige Teams diskutieren Richtlinien im IRC, entweder ad hoc oder während eines regelmäßig geplanten Meetings, und treffen dort Entscheidungen. Einige Teams nutzen die Mailingliste für diese Diskussionen. Der PTL des Teams ist dafür verantwortlich, sicherzustellen, dass die Diskussion verwaltet wird und das Ergebnis kommuniziert wird (entweder durch direkte Kommunikation oder indem sichergestellt wird, dass die Aufgabe an jemand anderen delegiert wird).

Alle Team-Politik-Entscheidungen müssen mit den vom Technical Committee festgelegten Gesamtrichtlinien kompatibel sein. Da das TC tendenziell breitere Governance-Entscheidungen trifft, die für die gesamte Mitwirkenden-Community gelten, ist der Prozess zur Diskussion und Abstimmung über diese Entscheidungen formeller gestaltet, einschließlich der Angabe der benötigten Stimmenanzahl für die Annahme und der Mindestdauer für die Diskussion. Zum Beispiel erfordern die meisten Anträge 1/3 der Mitglieder (5) zur Annahme und müssen mindestens 3 Tage nach Erhalt ausreichender Stimmen zur Annahme offen bleiben, um sicherzustellen, dass Zeit für die Registrierung von Dissent bleibt. Einzelheiten finden Sie im Technical Committee Charter und in den Hausregeln.

Wesentliche Designentscheidungen werden normalerweise durch die Überprüfung eines **Spezifikationsdokuments** diskutiert, das einer PEP ähnelt und die Anforderungen, Alternativen und Implementierungsdetails abdeckt. Feedback wird von allen Mitwirkenden eingeholt, und dann werden Spezifikationen schließlich von Mitgliedern des Kernprüfungsteams eines Projekts genehmigt oder abgelehnt. Einige Teams benötigen nur 2 Prüfer zur Genehmigung eines Designs, während andere Teams eine stärkere Indikation von Konsens benötigen, bevor ein Design genehmigt wird. Jedes Team legt eine Frist für die Genehmigung von Spezifikationen innerhalb jedes Entwicklungszyklus fest, um Mitwirkende zu ermutigen, Designs für wesentliche neue Funktionen frühzeitig auszuarbeiten und Risiken durch späte Änderungen im Zyklus zu vermeiden.

Kleinere technische Entscheidungen werden typischerweise durch die Überprüfung des oder der Patches, die zur Implementierung der Änderung erforderlich sind, getroffen. Jeder kann jeden Patch überprüfen und technisches Feedback geben, aber letztendlich werden zwei Kernprüfer eines Teams benötigt, um die meisten Änderungen zu genehmigen (Ausnahmen werden oft für triviale Änderungen wie Tippfehler oder für Korrekturen gemacht, die das CI-Gating-System entlasten).

Kontroverser Entscheidungsprozess

Kontroverse oder einfach nur komplizierte Entscheidungen weiten sich häufig über die Überprüfung von Spezifikationen hinaus auf Diskussionen in Mailinglisten aus. Sie führen oft auch zu Diskussionen bei einem der regelmäßig stattfindenden persönlichen Community-Treffen. Da viele Mitglieder der Community nicht an diesen Veranstaltungen teilnehmen können, werden die Diskussionen zusammengefasst und endgültige Entscheidungen so weit wie möglich mit Online-Tools getroffen.

Der PTL ist dafür verantwortlich, zu entscheiden, wann ein Konsens für Entscheidungen, die ein einzelnes Team betreffen, erreicht wurde, und in seltenen Fällen, in denen kein Konsens erreicht wurde und eine Entscheidung unbedingt getroffen werden muss, die endgültige Entscheidung zu treffen. Das TC fungiert als ähnliche Entscheidungsinstanz für Fälle, in denen Probleme **zwischen** Teams nicht anders gelöst werden können. Eine solche Eskalation der Entscheidungsfindung ist selten notwendig, da die direkt beteiligten Mitwirkenden im Allgemeinen einen konsensualen Konsens bevorzugen, anstatt die Entscheidung an andere zu eskalieren.

Planung einer neuen Veröffentlichung

OpenStack hat etwa alle 6 Monate eine Hauptveröffentlichung. Dies sind koordinierte, datumsbasierte Veröffentlichungen, die die bis zu diesem Zeitpunkt abgeschlossene Arbeit aller Mitgliedsprojekte umfassen. Einige Projektteams veröffentlichen häufiger als alle 6 Monate (dies gilt insbesondere für Teams, die Bibliotheken für andere Teams entwickeln). Kleinere Veröffentlichungen werden tendenziell dann herausgegeben, wenn Inhalte (neue Features oder Fehlerbehebungen) vorhanden sind, die sie rechtfertigen.

Der Zeitplan für jeden Entwicklungszyklus mit Fristen und einem endgültigen Veröffentlichungstermin wird vom Release-Management-Team in Abstimmung mit den Foundation-Mitarbeitern vorgeschlagen (Veröffentlichungen sind generell am Kalender der persönlichen Veranstaltungen ausgerichtet), und dann hat die Community die Möglichkeit, Feedback zu geben, bevor die endgültigen Termine festgelegt werden.

Entscheidungen über Prioritäten für jeden Entwicklungszyklus werden auf Team- und TC-Ebene getroffen. Kernprüfungsteams priorisieren interne Arbeiten wie die Behebung von Fehlern und die Implementierung neuer Features. Das TC wählt Community-Ziele aus, die normalerweise eine gewisse Menge an Arbeit von allen Teams erfordern. Die Einigung auf diese Prioritäten zu Beginn jedes Zyklus hilft den Teams, ihre Arbeit zu koordinieren, was besonders wichtig ist, da die Implementierung Überprüfungen von mehreren Teammitgliedern erfordert.

Änderungen im Prozess im Laufe der Zeit

In den letzten 8 Jahren ist die Anzahl der OpenStack-Projektteams von 2 auf 63 gestiegen. Die Zusammensetzung des Technical Committee hat sich geändert, um diesem Wachstum Rechnung zu tragen. Ursprünglich bestand das TC aus PTLs, aber mit zunehmender Mitgliederzahl wurde es für die Gruppe unpraktisch, effektiv zu funktionieren.

Die Community war früher auch um „Programmbereiche“ und nicht um Projektteams organisiert. Ein Programmbereich deckte einen Funktionsumfang ab, wie z. B. das Sammeln von Telemetriedaten oder die Verwaltung von Block-Speicher. Diese Organisation scheiterte, als mehrere Teams von Leuten am selben Funktionsumfang mit unterschiedlichen Lösungen arbeiten wollten. Die Organisation von Teams um den Code, den sie liefern, ermöglicht es verschiedenen Teams, unterschiedliche Interpretationen derselben Anforderungen zu haben. Zum Beispiel arbeiten jetzt mehrere Teams an verschiedenen Deployment-Tools.

Schlüsselpersonen und ihre Funktionen

Die Schlüsselpersonen in der Jupyter-Governance sind der BDFL, Fernando Perez, und der Steering Council. Mitwirkenden können einen Sonderstatus als Kernmitwirkende erhalten. Einige können auch institutionelle Mitwirkende sein, also Einzelpersonen, die im Rahmen ihrer offiziellen Pflichten bei einem institutionellen Partner zum Projekt beitragen.

Fernando Perez, der Gründer des Projekts, ist der aktuelle und erste BDFL. Der BDFL kann so lange dienen, wie er möchte. Der BDFL-Nachfolgeplan ist im Haupt-Governance-Dokument beschrieben. Zusammenfassend kann der BDFL den nächsten BDFL ernennen. Als Zeichen der Höflichkeit wird erwartet, dass der BDFL den Steering Council konsultiert. Sollte der BDFL keinen Nachfolger ernennen können, wird der Steering Council einen empfehlen.

Kernmitwirkende sind Einzelpersonen, denen Rechte, wie z. B. Commit-Berechtigungen, verliehen werden, um im besten Interesse des Projekts in ihrem Fachgebiet oder Teilprojekt zu handeln. Ein bestehender Kernmitwirkender empfiehlt in der Regel, dass jemand Kernmitwirkenden-Rechte erhält, indem er einen Konsens von Projektleitern einholt, die erfahrene Kernmitwirkende sind und im README des Projekt-Repos aufgeführt sind.

Um als Mitglied des Steering Council empfohlen und eingeladen zu werden, muss eine Person ein Projektmitwirkender sein, der substanzielle Beiträge in Qualität und Quantität geleistet hat und dies über mindestens ein Jahr aufrechterhalten hat. Potenzielle Ratsmitglieder werden von bestehenden Ratsmitgliedern nominiert und vom bestehenden Rat gewählt, nachdem gefragt wurde, ob das potenzielle Mitglied interessiert und bereit ist, diese Funktion auszuüben.

Regelmäßiger Entscheidungsprozess

Project Jupyter besteht aus einer Reihe von GitHub-Organisationen und Teilprojekten innerhalb dieser Organisationen. Die Hauptarbeit erfolgt über GitHub Issues und Pull-Requests. Die Genehmigung eines Pull-Requests durch ein beliebiges Teammitglied ermöglicht dessen Zusammenführung ohne weiteren Prozess. Alle zusammengeführten Pull-Requests landen in der nächsten stabilen Version eines Teilprojekts.

Es gibt ein wöchentliches, öffentliches Projekt-weites Meeting, das aufgezeichnet und auf YouTube veröffentlicht wird. Einige größere GitHub-Organisationen, die Teilprojekte von Project Jupyter sind, z. B. JupyterLab und JupyterHub, können zusätzliche öffentliche Team-Meetings wöchentlich oder monatlich haben. Diskussionen finden auf Gitter, der Jupyter-Mailingliste und am häufigsten auf einem offenen Issue und/oder Pull-Request auf GitHub statt.

Kontroverser Entscheidungsprozess

Die Grundlagen der Governance von Project Jupyter sind:

• Offenheit & Transparenz
• Aktive Mitwirkung
• Institutionelle Neutralität

Während der täglichen Projektaktivitäten nehmen die Mitglieder des Steering Council als Gleichgestellte mit allen anderen Mitwirkenden und der Community an allen Diskussionen, Code-Reviews und anderen Projektaktivitäten teil. Bei diesen täglichen Aktivitäten haben die Ratsmitglieder aufgrund ihrer Ratsmitgliedschaft keine besonderen Befugnisse oder Privilegien. Es wird jedoch erwartet, dass die Ratsmitglieder aufgrund der Qualität und Quantität ihrer Beiträge und ihres Fachwissens über die Projektsoftware und -dienste nützliche Leitlinien, sowohl technische als auch in Bezug auf die Projektrichtung, für potenziell weniger erfahrene Mitwirkende geben.

Bei kontroversen Themen arbeitet die Mitwirkenden-Community zusammen, um potenzielle Lösungen zu verfeinern, nach Bedarf zu iterieren und Konsens aufzubauen, indem Informationen und Ansichten konstruktiv und offen geteilt werden. Der Steering Council kann Entscheidungen treffen, wenn die reguläre Community-Diskussion innerhalb einer angemessenen Zeit keinen Konsens zu einem Thema erzielt.

Abstimmung

Selten, wenn überhaupt, wird bei technischen Entscheidungen abgestimmt.

Bei anderen Projektfragen kann der Steering Council eine Abstimmung über eine Entscheidung per Governance-PR oder E-Mail-Vorschlag anrufen. Die Annahme erfordert mindestens 80 % der Stimmen des Steering Council und mindestens 2/3 der Stimmen müssen positiv sein.

Der BDFL kann allein handeln, um Änderungen anzunehmen oder abzulehnen oder die Entscheidung des Steering Council zu überstimmen; dies wäre jedoch ein extrem seltener Fall. Als Wohlwollender (Benevolent) wählt der BDFL in der Praxis diese Autorität dem Konsens der Community-Diskussionskanäle und des Steering Council zu überlassen.

Planung von Veröffentlichungen

Da Project Jupyter eine Reihe von Projekten hat, nicht nur ein einzelnes Projekt, wird die Release-Planung weitgehend von den Kernmitwirkenden eines Projekts gesteuert.

Änderungen im Prozess im Laufe der Zeit

Der Prozess ist im Laufe der Zeit konstant geblieben, und der Ansatz hat uns gute Dienste geleistet. Zukünftig wird die Projektleitung aus einem BDFL und einem Steering Council bestehen. Dieses Governance-Modell war eine Formalisierung dessen, was das Projekt tat (vor 2015, als das Haupt-Governance-Dokument vom Steering Council angenommen wurde), anstatt eine Richtungsänderung.

Schlüsselpersonen und ihre Funktionen

Das Projekt erkennt drei Arten von Mitwirkenden an: Mitglieder des Kernteams, das Technische Komitee und Fellows. Regelmäßige Kern-Commiter nutzen ihren „Commit-Bit“ nicht mehr, sondern verlassen sich darauf, dass Pull-Requests geprüft und angenommen werden. Das Technische Komitee steuert technische Entscheidungen. Fellows sind angestellte Auftragnehmer, die neue Tickets triagieren, Patches von Committern und der Community überprüfen und zusammenführen, auch nicht triviale.

Mitglieder des Kernteams werden durch Nominierung und Abstimmung innerhalb des Kernteams hinzugefügt, mit Veto des Technischen Komitees (bisher nicht ausgeübt). Das Technische Komitee wird alle 18 Monate (alle größeren Django-Releases) von und aus den Mitgliedern des Kernteams gewählt. Unterteams innerhalb des Kernteams werden nach Interesse selbst ausgewählt.

Regelmäßiger Entscheidungsprozess

Die meisten täglichen Entscheidungen werden von Fellows und manchmal anderen aktiven Kernteammitgliedern getroffen.

Das Kernteam stimmt über neue Mitglieder ab, was eine 4/5-Mehrheit der abgegebenen Stimmen erfordert, ohne Quorum-Anforderung. Das Technische Komitee hat Veto-Befugnisse. Diese Befugnis wurde noch nie ausgeübt.

Kontroverser Entscheidungsprozess

Das Technische Komitee genehmigt gelegentlich Django Enhancement Proposals (DEPs), aber diese sind selten. Der DEP-Prozess ist grob an PEPs angelehnt und in DEP 1 dokumentiert. DEPs werden hauptsächlich für das Design von großen neuen Features verwendet, aber auch für Informationen über allgemeine Richtlinien und Prozesse.

Eine Idee für eine DEP sollte zuerst öffentlich auf der django-developers Mailingliste geprüft werden. Nachdem sie grob validiert wurde, bildet der Autor ein Team mit drei Rollen:

• **Autoren**, die die DEP schreiben und die Diskussion leiten;
• **Implementierer**, die die Implementierung der DEP vorbereiten;
• ein **Shepherd**, der ein Kernentwickler ist und der Hauptprüfer der DEP sein wird.

Der Entwurf der DEP wird eingereicht, eine Nummer zugewiesen und diskutiert. Die Autoren sammeln Feedback und steuern die Diskussion, wie sie es für richtig halten. Vorgeschlagene Orte, um endlose offene Diskussionen zu vermeiden, sind: separate Mailinglisten, Wiki-Seiten, die Arbeit mit Pull-Requests an der DEP.

Nachdem die Feedback-Runde beendet ist, bittet der Shepherd das Technische Komitee um Prüfung und Stellungnahme. Das Komitee kann als Team über eine DEP entscheiden oder ein Mitglied zur Überprüfung und Entscheidung bestimmen.

In Fällen, in denen kein Konsens erzielt werden kann, hat das Technische Komitee das letzte Wort. Dies wurde nie ausgeübt.

Planung einer neuen Veröffentlichung

Veröffentlichungen erfolgen nach einem festen Zeitplan, mit einer Hauptversion alle 18 Monate. Mit bezahlten Fellows, die sicherstellen, dass die notwendige Arbeit erledigt wird, sind pünktliche Veröffentlichungen Routine.

Änderungen im Prozess im Laufe der Zeit

Django hatte ursprünglich zwei BDFLs: Jacob Kaplan-Moss und Adrian Holovaty. Sie traten 9 Jahre nach der Gründung des Projekts zurück (Adrians Beitrag, Jacobs Beitrag). Nach ihrem Rücktritt wurde der DEP-Prozess definiert.

Schlüsselpersonen und ihre Funktionen

Bei Microsoft gibt es ein formelles Design-Team und ein Release-Management-Team. Die Hauptperson hinter dem Projekt ist derzeit Anders Hejlsberg, da einige der ursprünglichen Teammitglieder das Unternehmen verlassen haben.

Regelmäßiger Entscheidungsprozess

Microsoft, wo das Projekt entwickelt wird, hat eine starke Planungskultur, sodass Entwicklungs-Roadmaps weit im Voraus veröffentlicht werden, Notizen von Design-Diskussionen, die bei Microsoft stattfinden, schnell veröffentlicht werden und Meetings manchmal per Skype übertragen werden.

Externe Beiträge sind durch Pull-Requests auf GitHub erwünscht. Vorschläge für neue Anwendungsfälle oder Funktionen werden über Issues auf GitHub eingereicht. Dies dient als Ad-hoc-Prozess im PEP-Stil. Es gibt auch einige Diskussionen in sozialen Medien (Twitter).

Kontroverser Entscheidungsprozess

Hejlsberg ist die zentrale Figur des Projekts in Bezug auf das Sprachdesign und synthetisiert die Bedürfnisse der Community zu einem kohärenten Ganzen. Es gibt keinen formellen Prozess für externe Beiträge zum Design der Sprache.

Das TypeScript-Team filtert und integriert Community-Vorschläge. Die Hauptvorteile dieses Setups sind ein starkes und konsistentes Design mit zuverlässiger Planung und Ausführung. Während die Absichten und Pläne transparent sind, ist der Nachteil dieses Modells, dass die Beteiligung der Community auf Pull-Requests und Vorschläge beschränkt ist.

Planung einer neuen Veröffentlichung

Microsoft legt den Release-Zeitplan fest und kommuniziert Termine und Funktionen weit im Voraus. Nightly Builds sind in der Regel stabil (mit einem erheblichen Anteil von Nutzern, die diese Release-Form nutzen).

Versionierte Releases erfolgen alle 1-3 Monate, mit einer Roadmap, die auf GitHub verfügbar ist.

Änderungen im Prozess im Laufe der Zeit

TypeScript ist wahrscheinlich das erste nennenswerte Projekt von Microsoft, das vollständig Open Source entwickelt wurde (im Gegensatz zu "Source-Available").

Das Open-Sourcing von TypeScript durch Microsoft war von Beginn des Projekts an ein geplante Funktion. Bevor die erste Open-Source-Version veröffentlicht wurde, wurde die Sprache vollständig von den Bedürfnissen der ursprünglichen Teams und der frühen internen Benutzer bestimmt. Das anfängliche Open-Sourcing erfolgte über die inzwischen eingestellte Microsoft CodePlex-Plattform. Es gab keine klar definierte Routine für die Annahme externer Beiträge. Das Engagement der Community nahm erheblich zu, nachdem das Projekt verschoben wurde.

Schlüsselpersonen und ihre Funktionen

Die Verantwortlichkeiten des Astropy Project Teams sind auf viele verschiedene Rollen verteilt [1], wobei eine Person häufig mehrere Rollen innehat.

Das Hauptgremium, das das Astropy-Projekt überwacht, ist das Astropy *Coordination Committee* (CoCo). Seine Hauptaufgaben sind die Bearbeitung finanzieller Angelegenheiten, die Genehmigung neuer Pakete, die dem Astropy-Projekt beitreten möchten, die Genehmigung oder Ablehnung von *Astropy Proposals for Enhancement* (APEs) [2] und im Allgemeinen alles, was "führungsorientiert" oder zeitkritisch ist. Zum Zeitpunkt der Abfassung hat das Komitee vier Mitglieder und kann wachsen oder schrumpfen, je nach den Anforderungen an das Komitee.

Regelmäßiger Entscheidungsprozess

Kontroverser Entscheidungsprozess

Einfachere kontroverse Entscheidungen werden in der Regel auf der astropy-dev Mailingliste [3] diskutiert, und nach angemessener Zeit gibt es entweder einen klaren Konsens/Kompromiss (was meistens der Fall ist) oder das CoCo trifft eine Entscheidung, um Stillstand zu vermeiden.

Komplexere Entscheidungen folgen dem APE-Prozess, der nach dem PEP-Prozess modelliert ist. Hier trifft das CoCo die endgültige Entscheidung, nachdem eine für alle offene Diskussionsphase verstrichen ist. Im Allgemeinen folgt das CoCo dem Konsens oder dem Mehrheitswillen.

Planung einer neuen Veröffentlichung

Das Timing der Haupt-Releases erfolgt nach einem festen Zeitplan (alle 6 Monate); alles, was zu diesem Zeitpunkt enthalten ist, wird veröffentlicht.

Änderungen im Prozess im Laufe der Zeit

Das CoCo und das Ethos der "Open Development" entstanden von Beginn des Projekts an nach einer Reihe von Abstimmungen unter interessierten Astronomie-nahen Python-Entwicklern und verwandten Software-Ingenieuren. Die Kernergebnisse dieser anfänglichen Diskussionen wurden im Dokument *Vision for Astropy* [4] festgehalten.

Die Existenz der formalen Rollen und die meisten anderen der oben genannten Punkte entwickelten sich schrittweise mit dem Wachstum der Community, wobei jede Entwicklung entweder dem APE-Prozess folgte oder dem regulären Prozess der Vorstellung eines Vorschlags zur Diskussion und Abstimmung auf astropy-dev [3]. Im Allgemeinen entwickelten sich alle als eine Art Ratifizierung bereits bestehender Praktiken, erst nachdem sie in der Praxis erprobt worden waren.

Selbstbewertung

Die Tatsache, dass jeder, der Zeit hat, sich einbringen und etwas vorschlagen (normalerweise per PR) oder für seine Präferenz abstimmen kann, führt zu dem Gefühl, "wir stecken alle zusammen drin", was zu einer besser koordinierten Anstrengung führt.

Darüber hinaus bedeutet die Funktion des CoCo als hauptsächlich entscheidendes Gremium, dass kein Diktator seine Macht durchsetzt, während gleichzeitig klare Ansprechpartner für externe Organisationen bestehen, die skeptisch gegenüber vollständig demokratischen Verwaltungsmodellen sind.

Referenzen

Schlüsselpersonen und ihre Funktionen

Microsoft hat eine Hierarchie, die letztendlich dem CEO unterstellt ist. Unter dem CEO gibt es eine Reihe von Organisationen, von denen einige auf Ingenieurprojekte spezialisiert sind (im Gegensatz zu Vertrieb, Marketing oder anderen Funktionen). Diese Ingenieurorganisationen gliedern sich grob in bedeutende Produktfamilien - zum Beispiel gab es eine "Windows-Gruppe", eine "Xbox-Gruppe" und eine "Server und Tools-Gruppe". Diese werden typischerweise von *Executive Vice Presidents* (EVPs) geleitet, die dem CEO unterstellt sind.

Unter jedem EVP gibt es viele *Corporate Vice Presidents* (CVPs), von denen jeder für ein oder mehrere Produkte verantwortlich ist. Diese Ebene ist für die Zwecke dieses PEP relevant - der CEO und die EVPs sind selten an den meisten Entscheidungsprozessen beteiligt, sondern setzen die Richtung, unter der die CVPs Entscheidungen treffen.

Jedes Produkt unter einem CVP hat ein Team, das aus *Program Managern* (PMs) und *Engineering Managern* besteht. Engineering Manager haben Teams von Ingenieuren, die größtenteils nicht in Entscheidungsfindung involviert sind, obwohl sie in einigen Fällen als Spezialisten eingesetzt werden können. Für den Rest dieses Abschnitts bezieht sich *Engineering* auf jeden vom Ingenieurteam, der mit einem technischen Fokus beiträgt, und *PM* bezieht sich auf jeden vom Programmmanagement-Team, der mit einem Kundenfokus beiträgt. Nach getroffenen Entscheidungen führt Engineering die Implementierungs- und Testarbeiten durch, und PM validiert mit den Nutzern, dass ihr Problem gelöst wurde.

(Dies ist tatsächlich eine enorme Vereinfachung, bis zu dem Punkt, an dem einige Personen in diesen Rollen von dieser Charakterisierung beleidigt sind. In Wirklichkeit leisten die meisten Personen in PM- oder Engineering-Rollen Arbeit, die die Grenze zwischen den beiden Rollen überschreitet, und so sollten sie als Begriff für die Arbeit behandelt werden, die jemand gerade tut, anstatt als Kennung oder Einschränkung für eine Person.)

Teams repräsentieren im Allgemeinen ein Feature, während der CVP ein Produkt repräsentiert. Zum Beispiel hat Visual Studio Code einen CVP, der letztendlich für Entscheidungen über dieses Produkt und seine Gesamtrichtung verantwortlich ist (im Kontext, der von seinem EVP festgelegt wurde). Aber viele Teams tragen Features zu Visual Studio Code bei.

Zur vollständigen Klarheit: Der CEO, die EVPs und die CVPs modifizieren niemals direkt den Quellcode. Ihre gesamte Rolle besteht darin, die Richtung für die ihnen unmittelbar unterstellten Personen festzulegen und kontroverse Entscheidungen zu schlichten.

Regelmäßiger Entscheidungsprozess

Änderungen am Produktcode, die für externe Benutzer nicht sichtbar sind, werden ausschließlich vom Engineering vorgenommen. Einzelne Ingenieure werden von einem designierten Engineering Manager Aufgaben zugewiesen oder können sich selbst zuweisen. Beförderung zu immer höheren Positionen spiegelt im Allgemeinen das Vertrauen in die Entscheidungsfähigkeit des Einzelnen wider, und erfahrenere Ingenieure werden befugt, Entscheidungen mit weniger Validierung vom Rest des Teams zu treffen. Die meisten Fehler werden durch diesen Prozess abgedeckt (d. h. die Behebung eines für den Benutzer sichtbaren Problems, ohne die beabsichtigte Erfahrung zu verändern, ist eine Engineering-Entscheidung).

Entscheidungen, die Benutzer eines bestimmten Features betreffen, werden vom PM-Team für dieses Feature getroffen. Sie werden alle verfügbaren Datenquellen nutzen, um ein Problem zu identifizieren, Alternativen zu experimentieren und schließlich ein Design-Dokument vorzubereiten. Erfahrene Mitglieder von PM und Engineering überprüfen Designs, um die Details zu klären, und schließlich wird ein Artefakt erstellt, auf das sich das Feature-Team einigt. Engineering wird dieses Artefakt zur Implementierung der Arbeit verwenden, und PM wird dieses Artefakt später verwenden, um zu validieren, dass das ursprüngliche Problem behoben wurde.

Von erfahrenen Mitgliedern der Engineering- und PM-Teams für ein Feature wird erwartet, dass sie Entscheidungen im Sinne der von ihrem CVP festgelegten Richtung treffen. Teams haben regelmäßige Treffen mit ihrem CVP, um die jüngsten Entscheidungen zu besprechen und die Konsistenz sicherzustellen. Entscheidungen, die nicht offensichtlich im Einklang mit den Erwartungen des CVP stehen, werden im kontroversen Prozess eskaliert.

Kontroverser Entscheidungsprozess

Wenn Entscheidungen eine teamübergreifende Koordination erfordern oder nicht offensichtlich mit früheren CVP-Richtlinien übereinstimmen, eskalieren die Teams die Entscheidungsfindung. Dazu gehören oft Entscheidungen, die eine Richtungsänderung beinhalten, den Versuch, eine neue oder andere Benutzergruppe zu erreichen, die Einstellung und Entfernung bedeutender Features (oder innerhalb eines kurzen Zeitrahmens) oder Änderungen, die schnelle Releases erfordern.

Im Allgemeinen sind CVPs nicht mit allen Aspekten der Arbeit des Feature-Teams vertraut. Daher muss das Feature-Team sowohl eine Empfehlung als auch ausreichenden Kontext für die Entscheidung liefern, damit der CVP *ohne zusätzliche Kenntnisse* entscheiden kann. Meistens führt der erste Versuch zu einer Reihe von Fragen des CVP, die das Team recherchiert, beantwortet und die Entscheidung zu einem späteren Zeitpunkt erneut versucht.

Häufige Fragen von CVPs sind:

• Wie viele Benutzer sind von dieser Entscheidung betroffen?
• Was ist der Plan zur Minimierung der Auswirkungen auf aktuelle Benutzer?
• Wie wird die Änderung für potenzielle Benutzer "verkauft"/beschrieben?

Von CVPs wird erwartet, dass sie ein starkes Verständnis des gesamten Bereichs haben, damit sie einige Fragen selbst beurteilen können, wie z. B.:

• Welche ähnlichen Entscheidungen wurden von anderen Projekten innerhalb von Microsoft getroffen?
• Welche anderen Projekte haben Pläne, die diese Entscheidung beeinflussen könnten?
• Welche ähnlichen Entscheidungen wurden von Projekten außerhalb von Microsoft getroffen?
• Brauchen die Benutzer es?
• Entspricht es der von ihrem EVP festgelegten Richtung?

Entscheidungen, die von CVPs getroffen werden, sind im Allgemeinen willkürlich und endgültig, obwohl sie in der Regel ihre Begründung angeben.

Planung einer neuen Veröffentlichung

Releases beinhalten die Koordination einer Reihe von Feature-Teams und versuchen daher selten, die Eingaben aller Teams einzubeziehen. Ein Zeitplan wird auf der Grundlage breiterer Ökosystembedürfnisse festgelegt, wie z. B. geplante Veranstaltungen/Konferenzen oder Gelegenheiten, Medienaufmerksamkeit zu nutzen.

Teams werden über das Release-Datum, das Thema des Releases informiert und planen dann ihre eigenen Aktivitäten gemäß dem oben genannten Entscheidungsprozess. Die Änderung des Release-Datums gilt als kontroverse Entscheidung.