Thema: maintainership
-
Nach Eingang eines Schwachstellenberichts: bestätigen, bewerten, privat beheben, offenlegen
Sobald ein Bericht die Sicherheitskontaktstelle des Projekts erreicht, ist die Arbeit eine Abfolge mit Terminen: schnell bestätigen, klassifizieren (wie vorgesehen, Bug, Feature-Wunsch, Schwachstelle), mit der meldenden Person ein Embargo vereinbaren, den Fix privat entwickeln, eine CVE-Kennung beschaffen, dann veröffentlichen und ein Advisory publizieren, das betroffene und behobene Versionen nennt und die meldende Person würdigt. Der OpenSSF-Leitfaden für Maintainer und GitHubs Hinweise zur Offenlegung beschreiben diesen Prozess; dieser Artikel fasst ihn für ein Projekt mit ein bis fünf Maintainern zusammen.
-
Issue-Triage für ein kleines Projekt: ein fester Label-Satz und ein regelmässiger Durchgang
Triage bedeutet, für jedes neue Issue zu entscheiden, was es ist, ob es umsetzbar ist und wer als Nächstes am Zug ist. Ein kleines Label-Vokabular in drei Familien (Typ, Status, Bereich) sowie ein kurzer Durchgang in festem Rhythmus hält den Tracker ehrlich; GitHubs Standard-Labels (darunter bug, enhancement, documentation, duplicate, question, wontfix, good first issue und help wanted) sind ein brauchbarer Startsatz.
-
Mitwirkende würdigen: eine Contributors-Tabelle nach Beitragsart, ohne Rangfolge
Die All-Contributors-Spezifikation verlangt einen Contributors-Abschnitt an prominenter Stelle, als Tabelle aus Name, Link und Beitragskategorie, jede Art von Beitrag auf jedem Niveau einschliessend, wobei die Reihenfolge unerheblich ist; sie rät davon ab, jemanden wegen eines als gering empfundenen Beitragsumfangs auszuschliessen. Gits Co-authored-by-Trailer würdigt Ko-Autorinnen eines einzelnen Commits. Zusammen erlauben sie es einem kleinen Projekt, Dokumentation, Triage, Design und Berichte zu würdigen, nicht nur gemergten Code.
-
Release-Kadenz für ein kleines Projekt: zeitbasierte Züge versus Release-wenn-bereit
Eine Versionsnummer sagt, was ein Release verspricht; eine Kadenz-Richtlinie sagt, wann Releases stattfinden. Rust liefert alle sechs Wochen ein Stable-Release aus einem Nightly-Beta-Stable-Zug, Python wechselte mit PEP 602 zu einem jährlichen Feature-Release, und Django gibt Feature-Releases nach einem zeitbasierten Zeitplan heraus, mit Patch-Releases bei Bedarf. Ein kleines Projekt kann diese Form übernehmen: Feature-Releases nach Kalender oder sobald sich etwas Nennenswertes angesammelt hat, Patch-Releases, sobald eine Korrektur fertig ist.
-
Eine CONTRIBUTING-Datei, die einem Neuling die ersten fünf Fragen beantwortet
Bevor ein potenzieller Mitwirkender Code schreibt, stellt er sich folgende Fragen: Ist diese Änderung erwünscht, wie schlage ich sie vor, was muss ein Pull Request enthalten, wie lange dauert es bis zu einer Antwort, und wie gelangt eine gemergte Änderung zu den Nutzern? Eine CONTRIBUTING-Datei, die diese fünf Fragen der Reihe nach beantwortet und für alles Weitere verlinkt, soll Pull Requests vorbeugen, die wegen Umfangs oder fehlender Tests abgelehnt würden.
-
Eine Feature-Anfrage ablehnen, ohne den Beitragenden zu verlieren
Eine Ablehnung, die sich auf einen schriftlich festgehaltenen Projektumfang beruft, zeitnah erfolgt, eine Alternative nennt und den Thread schliesst, ist freundlicher als Schweigen und behält die anfragende Person als Beitragende. Die Open Source Guides halten fest, dass Schriftlichkeit das Nein-Sagen erleichtert und dass eine Antwort selten mehr als ein oder zwei Sätze braucht.
-
Governance für ein kleines Projekt: Entscheidungsrechte festgehalten, bevor sie gebraucht werden
Eine Governance-Datei beantwortet, wer mergen darf, wer einen Streit über den Projektumfang entscheidet, wie Maintainer hinzugefügt und entfernt werden und wie sich die Regeln selbst ändern. Pythons PEP 13 zeigt ein Ratsmodell mit einer Autorität, die absichtlich selten genutzt und öffentlich beraten werden soll; das Apache-Glossar definiert Lazy Consensus, wonach ein Vorschlag angenommen ist, wenn innerhalb einer festgelegten Frist niemand widerspricht. Ein Projekt mit ein bis drei Maintainern braucht nur eine Seite.
-
Wie verbringen Maintainer kleiner Projekte ihre Zeit tatsächlich, und was hat die Aufteilung vom Schreiben von Code weg verschoben?
Offene Frage: Die Open Source Guides beobachten, dass Maintainer weitverbreiteter Projekte letztlich weniger Code schreiben und mehr auf Issues antworten, und empfehlen als Abhilfe Dokumentation, Neinsagen, das Verteilen der Last und Automatisierung; was fehlt, sind gemessene Zeiten pro Tätigkeit für kleine Projekte und Belege dafür, welche dieser Massnahmen die Aufteilung tatsächlich verändert haben.
-
Übergabe der Maintainer-Rolle und Bus-Faktor: was eine Nachfolgeperson am ersten Tag können muss
Ein Projekt überlebt seine Maintainer-Person, wenn eine zweite Person bereits jedes Konto und jeden Schlüssel besitzt, ein Release allein anhand der schriftlich festgehaltenen Schritte durchführen kann und weiss, wo Entscheidungen festgehalten sind. PEP 541 zeigt, was sonst auf PyPI geschieht: Ein Projekt gilt erst dann als verlassen, wenn die besitzende Person unerreichbar ist, zwölf Monate lang keine Version erschienen ist und die Startseite keine Aktivität zeigt, und erst dann kann es gemäss der Regel für verlassene Projekte an eine neue besitzende Person übergeben werden. Der Repository-Transfer von GitHub verschiebt Issues, Pull Requests, Sterne und Watcher zusammen mit dem Code.
-
Supporting several release lines: which fixes go where
A support policy is a table of release lines with a status each (feature, bugfix, security-only, end of life) and a rule for which fix classes are backported to which lines. Python maintains a series with bugfix releases for two years and security-only releases for three more; Django backports critical fixes to the last feature release and security and data-loss fixes to the last two plus long-term-support lines; Rust supports only the most recent stable. A small project should publish the table and default to the narrowest promise it can keep.
Maschinenlesbar: JSON