Une journée de documentation planifiée attire plus de nouveaux contributeurs qu'un appel permanent à l'aide pour la documentation

Hypothèse

Dans les petits projets, les tickets de documentation portent généralement sur des tâches limitées, autonomes et que l'on peut confier sans risque à des inconnus, ce qui explique leur étiquette good first issue ; la documentation de GitHub classe cette étiquette parmi celles créées par défaut dans chaque dépôt et la décrit comme signalant les tickets adaptés aux personnes qui contribuent pour la première fois. Pourtant, de tels tickets peuvent rester ouverts pendant des mois. L'hypothèse est que l'ingrédient manquant n'est pas la tâche mais le moment : une journée fixée à l'avance pour laquelle un mainteneur promet une revue le jour même, avec les tâches réunies en un seul endroit et accompagnées d'une phrase indiquant par où commencer, et une invitation annoncée une semaine avant. Ce jour-là, le coût de la contribution (l'incertitude quant à savoir si quelqu'un examinera le travail et si la tâche est toujours souhaitée) est au plus bas, ce qui amène les personnes qui se contentaient d'observer à effectuer leur première modification. L'affirmation porte précisément sur les personnes qui contribuent pour la première fois et sur les modifications fusionnées, pas sur le volume de documentation écrite.

Prédiction

Pour un projet qui organise une journée de documentation, le nombre de modifications de documentation fusionnées et rédigées par des personnes qui contribuent pour la première fois, sur les sept jours entourant l'événement, est plus élevé que sur n'importe quelle autre fenêtre de sept jours de l'année précédente, et plus élevé que le total obtenu pour la même liste de tickets pendant les mois où elle était ouverte avant l'événement. Prédiction secondaire : une partie de ces personnes effectue une seconde contribution dans les trois mois suivants, à un taux supérieur à celui des personnes ayant contribué pour la première fois au code du même projet.

Test proposé

1. Préparer la liste : de huit à vingt tickets de documentation, chacun avec un emplacement, des critères d'achèvement et l'étiquette good first issue, publiés deux semaines à l'avance avec la date et la promesse de revue.
2. Le jour venu, un mainteneur examine uniquement les pull requests de documentation et répond dans l'heure pendant les horaires annoncés ; rien d'autre ne change dans le projet.
3. Consigner, pour chaque modification de documentation fusionnée sur les douze mois précédents et sur la fenêtre de l'événement : l'auteur, le fait qu'il s'agisse ou non de sa première contribution, et le délai entre la pull request et la fusion.
4. Comparer la fenêtre de l'événement à chacune des autres fenêtres de sept jours de l'année pour les nouveaux contributeurs et les modifications fusionnées ; présenter les rangs, pas seulement les moyennes, puisqu'une fenêtre est comparée à de nombreuses autres.
5. Suivre le taux de seconde contribution sur les trois mois suivant l'événement et le comparer à celui des personnes ayant contribué pour la première fois au code pendant la même période.

Statut

Aucun résultat n'est avancé. Un seul événement ne permet pas de dissocier l'effet de la journée de celui de l'annonce ou de la liste sélectionnée ; répéter la journée avec et sans annonce, ou annoncer la liste sans fixer de jour, serait l'étape suivante si la première comparaison révèle un effet.