Ein terminierter Dokumentations-Tag bringt mehr Erstbeitragende als ein dauerhafter Aufruf zur Mithilfe an der Dokumentation

Hypothese

Dokumentations-Issues in kleinen Projekten sind meist klein, in sich abgeschlossen und gefahrlos an fremde Personen zu vergeben, weshalb sie mit good first issue beschriftet werden; die Dokumentation von GitHub zählt dieses Label zu den Standardlabels, die in jedem Repository angelegt werden, und beschreibt es als Kennzeichnung von Issues, die für Erstbeitragende geeignet sind. Dennoch können solche Issues monatelang offen bleiben. Die Hypothese lautet, dass die fehlende Zutat nicht die Aufgabe ist, sondern der Zeitpunkt: ein fester Tag, an dem ein Maintainer eine Prüfung am selben Tag zusagt, an dem die Aufgaben an einem Ort mit einem Satz zum Einstieg aufgelistet sind und an dem die Einladung eine Woche im Voraus angekündigt wird. An diesem Tag ist der Aufwand des Mitwirkens (die Unsicherheit, ob überhaupt jemand hinschaut, ob die Aufgabe noch gewünscht wird) am geringsten, sodass Personen, die bisher nur zugeschaut haben, ihre erste Änderung einreichen. Die Behauptung betrifft speziell Erstbeitragende und gemergte Änderungen, nicht die Menge der geschriebenen Dokumentation.

Vorhersage

Für ein Projekt, das einen Dokumentations-Tag durchführt, ist die Anzahl der von Erstbeitragenden verfassten und gemergten Dokumentationsänderungen in den sieben Tagen rund um das Ereignis höher als in jedem anderen Sieben-Tage-Fenster des vorangegangenen Jahres, und höher als die Gesamtzahl für dieselbe Issue-Liste während der Monate, in denen sie vor dem Ereignis offen war. Eine sekundäre Vorhersage: Ein Anteil dieser Beitragenden leistet innerhalb der folgenden drei Monate einen zweiten Beitrag, und zwar mit einer höheren Quote als Erstbeitragende bei Code im selben Projekt.

Vorgeschlagener Test

1. Die Liste vorbereiten: acht bis zwanzig Dokumentations-Issues, jedes mit einem Ort, einer Definition von «fertig» und dem Label good first issue, zwei Wochen im Voraus veröffentlicht zusammen mit dem Datum und der Zusage zur Prüfung.
2. Am Tag selbst prüft ein Maintainer ausschliesslich Pull Requests zur Dokumentation und antwortet während der angekündigten Stunden innerhalb einer Stunde; am Projekt ändert sich sonst nichts.
3. Für jede gemergte Dokumentationsänderung der vorangegangenen zwölf Monate sowie des Ereignisfensters festhalten: die beitragende Person, ob es sich um ihren ersten Beitrag handelte, Zeit vom Pull Request bis zum Merge.
4. Das Ereignisfenster mit jedem anderen Sieben-Tage-Fenster des Jahres hinsichtlich Erstbeitragenden und gemergter Änderungen vergleichen; die Ränge berichten, nicht nur die Mittelwerte, da ein Fenster mit vielen verglichen wird.
5. Die Quote zweiter Beiträge drei Monate nach dem Ereignis verfolgen und mit Erstbeitragenden bei Code aus demselben Zeitraum vergleichen.

Status

Es wird kein Ergebnis behauptet. Ein einzelnes Ereignis kann den Tag nicht von der Ankündigung oder der kuratierten Liste trennen; die Wiederholung des Tages mit und ohne Ankündigung oder die Ankündigung der Liste ohne einen Tag wäre der nächste Schritt, falls der erste Vergleich einen Effekt zeigt.