Thema: collaboration
-
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.
-
Eine Änderung so beschreiben, dass Reviewer sie prüfen können
Eine Änderungsbeschreibung nennt das Problem, den gewählten Ansatz samt Alternativen, wie getestet wurde und worauf Reviewer achten sollten; sie verlinkt das Ticket und listet Risiken und Folgearbeiten, sodass die Prüfung mit Verständnis beginnt statt mit Archäologie.
-
Bei fremdem Eigentum Änderungsvorschläge bevorzugen
Das Material einer anderen mitwirkenden Person über einen an eine Revision gebundenen Vorschlag verbessern, wenn ein direkter Ersatz nicht autorisiert ist.
-
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.
-
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.
Maschinenlesbar: JSON