NuGet-Governance

Artikel
08/10/2023

Dieser Artikel basiert auf dem Governancemodell des wohlmeinenden Diktators der University of Oxford. Es steht unter der Creative Commons-Lizenz Namensnennung-Weitergabe unter gleichen Bedingungen 2.0 UK: England & Wales.

Das NuGet-Projekt wird von einem wohlmeinenden Diktator geleitet und von der Community verwaltet. Das bedeutet, dass die Community aktiv an der täglichen Wartung des Projekts mitwirkt, aber die strategische Leitung dem wohlmeinenden Diktator zufällt. Im Zweifelsfall hat der wohlmeinende Diktator das letzte Wort.

Die Aufgabe des wohlmeinenden Diktators ist es, Uneinigkeit innerhalb der Community zu klären und sicherzustellen, dass das Projekt koordiniert bearbeitet wird. Es ist wiederum die Aufgabe der Community, dem wohlmeinenden Diktator die Entscheidungsfindung durch aktive Teilnahme und engagiertes Mitwirken zu ermöglichen.

Rollen und Zuständigkeiten

An dieser Stelle werden vier Rollen beschrieben: der wohlmeinende Diktator, Committer, Mitwirkende und Benutzer.

Wohlmeinender Diktator

Das NuGet-Kernteam weist selbst einen wohlmeinenden Diktator oder eine Projektleitung zu. Da die Community immer forken kann, ist das Team für die Community verantwortlich. Die Projektleitung muss die Community als Ganzes verstehen und sich bemühen, so viele unterschiedliche Bedürfnisse wie möglich zu erfüllen, während gleichzeitig das langfristige Bestehen des Projekts sichergestellt wird.

In vielerlei Hinsicht besteht die Rolle des wohlmeinenden Diktators weniger im Bestimmen als im Vermitteln. Der entscheidende Punkt ist, den Richtigen Verantwortung für das Projekt zu übertragen, während dieses wächst, sodass die Community gemeinsam die Idee der Projektleitung verwirklichen kann. Die Aufgabe der Projektleitung ist es, sicherzustellen, dass die Committers (siehe unten) die für das Projekt richtigen Entscheidungen treffen. Prinzipiell bedeutet dies, dass die Projektleitung nicht in deren Vorgehen eingreift, solange dieses der Strategie des Projekts entspricht.

Zusätzlich ist die Projektleitung die wichtigste bzw. die erste Anlaufstelle für NuGet für .NET Foundation-Mitarbeiter bei Geschäftsvorgängen wie der Domänenregistrierung und bei technischen Diensten (z.B. Codesignierung).

Committers

Committers sind Mitwirkende, die nützliche Beiträge zu NuGet geleistet haben. Sie werden vom wohlmeinenden Diktator ernannt. Ab ihrer Ernennung sollen Committers sowohl Code direkt in das Repository schreiben als auch die Beiträge anderer überprüfen. Committers sind häufig Entwickler, können aber auch anderweitig zu einem Projekt beitragen.

Normalerweise konzentriert sich ein Committer auf einen bestimmten Aspekt des Projekts. Dabei bringt er wichtiges Fachwissen und ein umfassendes Verständnis mit, die für das Projekt wesentlich sind. Die Rolle eines Committers ist keine offizielle Rolle, sondern eine Position, die einflussreiche Mitglieder der Community einnehmen, um die Projektleitung zu unterstützen.

Committers haben bei der Ausrichtung von NuGet keine Entscheidungsgewalt. Allerdings haben sie das Vertrauen der Projektleitung, die mit Fragen an sie herantritt. Committers sollen sicherstellen, dass die Projektleitung über die Bedürfnisse und die gemeinsamen Ziele der Community informiert ist, und sie sollen Beiträge zum Projekt leisten oder in die Wege leiten. Häufig erhalten Committers die inoffizielle Kontrolle über ihren Zuständigkeitsbereich, und ihnen werden Berechtigungen zum direkten Anpassen gewisser Abschnitte des Quellcodes erteilt. Das heißt also, dass Committers zwar keine Entscheidungsbefugnis haben, ihre Handlungen aber häufig mit den Entscheidungen der Projektleitung übereinstimmen.

Beitragende

Mitwirkende sind Mitglieder der Community, die Patches in NuGet einreichen. Diese Patches können sowohl einmal als auch mehrmals über einen längeren Zeitraum vorkommen. Es wird erwartet, dass Mitwirkende Patches einreichen, die zunächst klein sind und mit wachsendem Vertrauen des Mitwirkenden, der Committers und der Projektleitung in die Qualität von Patches des Mitwirkenden immer größer werden. Mitwirkende werden in den Anmerkungen zu der jeweiligen Version des Produkts anerkannt.

Bevor der erste Patch eines Mitwirkenden in das Repository aufgenommen wird, muss er eine Lizenzvereinbarung für Mitwirkende oder einen Abtretungsvertrag für .NET Foundation unterzeichnen. Der Patch kann eingereicht und besprochen werden, aber er kann ohne die entsprechenden Dokumente nicht im Repository committet werden. Senden Sie eine E-Mail an contributions@nuget.org, um eine Lizenzvereinbarung für Mitwirkende anzufordern.

Reichen Sie einen Pull Request in einem der folgenden Repositorys ein, um Mitwirkender zu werden:

Der genaue Prozess zum Einreichen eines Pull Requests unterscheidet sich je nach Repository:

Benutzer

Benutzer sind Mitglieder der Community, die NuGet benötigen und verwenden, sei es als Paketnutzer oder als -ersteller (oder beides). Benutzer sind die wichtigsten Mitglieder der Community, denn ohne sie hätte das Projekt keinen Nutzen. Jeder kann ein Benutzer sein. Es gibt keine besonderen Anforderungen.

Benutzer werden dazu angehalten, sich so viel wie möglich am Lebenszyklus von NuGet und an der Community zu beteiligen. Durch Beiträge von Benutzern kann das Projektteam sicherstellen, dass sie auf die Bedürfnisse der Benutzer eingehen. Zu üblichen Benutzeraktivitäten zählt u.a. Folgendes:

das Einsetzen für den Gebrauch des Pakets
das Melden der Stärken und Schwächen eines Projekt aus der Perspektive eines neuen Benutzers
moralische Unterstützung (auch mal Danke sagen)
Schreiben von Dokumentationen und Tutorials
Einreichen von Problemberichten und Featureanforderungen
die Teilname an Communityereignissen wie Bug Bashes
das Beteiligen an Diskussionen oder in Foren

Wenn Benutzer sich fortlaufend an einem Projekt und der dazugehörigen Community beteiligen, wird ihre Beteiligung immer größer. Dann kann es sein, dass diese Benutzer wie oben beschrieben zu Mitwirkenden werden.

Nachfolge unter besonderen Umständen

Wenn der Besitzer eines NuGet-Kontos arbeitsunfähig ist oder verstirbt, versuchen wir in Zusammenarbeit mit der Community einen oder mehrere Nachfolger als Besitzer für Pakete zu finden, für die das betroffene Konto der alleinige Besitzer war und die unter einer OSI-genehmigten Lizenz veröffentlicht wurden. Um den Besitz zu beantragen, müssen Sie uns folgende Dokumente schicken:

eine Kopie Ihres Ausweises mit Foto.
Eines der folgenden Dokumente zum Nachweis des Status des früheren Kontoinhabers:
- eine offizielle, von der Regierung ausgestellte Sterbeurkunde, wenn der vorherige Besitzer verstorben ist, oder
- eine Bescheinigung, z.B. eine ärztliche Bescheinigung, in der bestätigt wird, dass der Kontoinhaber arbeitsunfähig ist.
Eines der folgenden Dokumente zum Nachweis Ihres Eigentumsrechts:
- eine Heiratsurkunde, die belegt, dass Sie der Ehepartner des verstorbenen Kontoinhabers sind,
- eine unterschriebene Bevollmächtigung,
- eine Kopie eines Testaments oder Treuhanddokuments, die Sie als Vollstrecker oder Begünstigten nennen,
- eine Geburtsurkunde des Kontoinhabers, falls Sie ein Elternteil sind oder
- Vormundschaftsdokumente, falls Sie der Vormund des Kontoinhabers sind.

Falls Sie diese Vorkehrung in Anspruch nehmen müssen, senden Sie uns eine E-Mail an support@nuget.org mit der ID und der Version des Pakets.

Transparency

Der Erfolg eines Open Source-Projekts hängt im Wesentlichen vom Vertrauen der Community in die Governance ab. Deshalb müssen Entscheidungen transparent und offen getroffen werden. Eine Diskussion über die Ausrichtung eines Projekts muss öffentlich geführt werden. Die Community sollte niemals von einer Entscheidung des wohlmeinenden Diktators überrascht werden. Darüber hinaus müssen Diskussionen über Projektentscheidungen archiviert werden, damit Mitglieder der Community den Prozess und Kontext einer Entscheidung verstehen können.