Ein terminierter Dokumentationstag bringt mehr Erstbeitragende als ein dauerhafter Aufruf zur Mithilfe an der Dokumentation

Hypothese

Dokumentations-Issues in kleinen Projekten sind typischerweise klein, in sich abgeschlossen und lassen sich gefahrlos Fremden übergeben, weshalb sie mit good first issue gekennzeichnet werden; die GitHub-Dokumentation führt dieses Label unter den Standardlabels auf, die in jedem Repository angelegt werden, und beschreibt es als Kennzeichnung von Issues, die sich für Erstbeitragende eignen. Trotzdem können solche Issues monatelang offen bleiben. Die Hypothese lautet, dass die fehlende Zutat nicht die Aufgabe, sondern der Zeitpunkt ist: ein fester Tag, an dem ein Maintainer ein Review noch am selben Tag verspricht, die Aufgaben an einem Ort mit einem Satz zum Einstieg aufgelistet sind und die Einladung eine Woche im Voraus angekündigt wird. An diesem Tag sind die Kosten des Beitragens (die Unsicherheit, ob überhaupt jemand hinschaut, ob die Aufgabe noch gewünscht ist) am geringsten, sodass Personen, die bisher nur zugeschaut haben, ihre erste Änderung vornehmen. Die Behauptung bezieht sich gezielt auf Erstbeitragende und auf gemergte Änderungen, nicht auf die Menge der geschriebenen Dokumentation.

Vorhersage

Bei einem Projekt, das einen Dokumentationstag 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 zweite Vorhersage: Ein Teil 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 einer Fundstelle, einer Definition von „fertig“ und dem Label good first issue, veröffentlicht zwei Wochen im Voraus zusammen mit dem Datum und dem Review-Versprechen.
2. Am Tag selbst prüft ein Maintainer ausschliesslich Pull Requests zur Dokumentation und antwortet innerhalb einer Stunde während der angekündigten Zeiten; sonst ändert sich am Projekt nichts.
3. Für jede gemergte Dokumentationsänderung über die vorangegangenen zwölf Monate und das Ereignisfenster festhalten: Autor oder Autorin, ob es der erste Beitrag der Person war, Zeit vom Pull Request bis zum Merge.
4. Das Ereignisfenster mit jedem anderen Sieben-Tage-Fenster des Jahres hinsichtlich Erstautorinnen und -autoren sowie 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 festen Tag wäre der nächste Schritt, falls der erste Vergleich einen Effekt zeigt.