Thema: open-source
-
Ein terminierter Dokumentationstag bringt mehr Erstbeitragende als ein dauerhafter Aufruf zur Mithilfe an der Dokumentation
Hypothese: Ein Projekt, das einen einzelnen Tag mit einer kuratierten Liste kleiner Dokumentations-Issues ankündigt, an dem Maintainer für ein Review am selben Tag verfügbar sind und jede Aufgabe das Label good-first-issue trägt, erhält mehr gemergte Dokumentationsänderungen von Personen, die zuvor noch nie beigetragen haben, als dieselbe Liste, die das ganze Jahr über offen bleibt; ein vorgeschlagener Vergleich anhand der eigenen Historie eines Projekts.
-
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.
-
Eine Funktion in einer Bibliothek als veraltet markieren: warnen, den Ersatz dokumentieren, planmässig entfernen
Eine Deprecation in einer Bibliothek besteht aus vier Teilen: einem Ersatz, der zuerst existiert, einer Laufzeitwarnung zusammen mit einem Dokumentationshinweis, der Version und Ersatz nennt, einem Eintrag im Changelog und einer Entfernungs-Version, die im Voraus durch eine Richtlinie festgelegt wird. PEP 387 verlangt bei Pythons jährlichem Rhythmus eine Deprecation-Frist von mindestens zwei Jahren und beschreibt eine rein dokumentarische «Soft Deprecation»; Django entfernt Übergangslösungen (Shims) frühestens zwei Feature-Releases nach der Warnung.
-
Repositorys, deren Setup als ein einziger geprüfter Befehl läuft, erhalten mehr Erstbeiträge als Repositorys mit manueller Setup-Liste
Hypothese: Das README „Scripts To Rule Them All“ von GitHub behauptet, dass eine geringere Setup-Reibung der Schlüssel zu schnelleren und zufriedeneren Beiträgen ist; der Vorschlag formuliert dies messbar um und sagt voraus, dass Repositorys mit einem einzigen, sich selbst prüfenden Setup-Befehl mehr Pull Requests von Erstbeitragenden zeigen, davon mehr beim ersten Push grün sind, und weniger Setup-Probleme aufweisen als vergleichbare Repositorys mit manuellen README-Schritten.
-
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