Un día programado de documentación atrae a más contribuyentes primerizos que una convocatoria permanente de ayuda con la documentación

Hipótesis

Las incidencias de documentación en proyectos pequeños suelen ser pequeñas, autocontenidas y seguras para encargar a personas desconocidas, razón por la que se etiquetan como good first issue; la documentación de GitHub incluye esa etiqueta entre las creadas por defecto en cada repositorio y la describe como marca de incidencias adecuadas para quienes contribuyen por primera vez. Aun así, esas incidencias pueden permanecer abiertas durante meses. La hipótesis es que lo que falta no es la tarea sino el momento: un día fijo en el que una persona mantenedora promete revisión el mismo día, las tareas se listan en un solo lugar con una frase sobre por dónde empezar, y la invitación se anuncia con una semana de antelación. En ese día el costo de contribuir (la incertidumbre de si alguien va a mirar, de si la tarea todavía se desea) es el más bajo, así que quienes solo observaban hacen su primer cambio. La afirmación se refiere específicamente a contribuyentes primerizos y a cambios fusionados, no al volumen de documentación escrita.

Predicción

Para un proyecto que organiza un día de documentación, el número de cambios de documentación fusionados escritos por contribuyentes primerizos en los siete días alrededor del evento es mayor que en cualquier otra ventana de siete días del año anterior, y mayor que el total de la misma lista de incidencias durante los meses en que estuvo abierta antes del evento. Una predicción secundaria: una parte de esos contribuyentes hace una segunda contribución dentro de los tres meses siguientes, a una tasa mayor que la de contribuyentes de código primerizos del mismo proyecto.

Prueba propuesta

1. Preparar la lista: entre ocho y veinte incidencias de documentación, cada una con una ubicación, una definición de terminado y la etiqueta good first issue, publicadas dos semanas antes junto con la fecha y la promesa de revisión.
2. El día del evento, una persona mantenedora revisa solo pull requests de documentación y responde en menos de una hora durante el horario anunciado; nada más cambia en el proyecto.
3. Registrar, por cada cambio de documentación fusionado durante los doce meses anteriores y la ventana del evento: autoría, si fue la primera contribución de esa persona, y el tiempo entre el pull request y la fusión.
4. Comparar la ventana del evento con cualquier otra ventana de siete días del año en cuanto a autores primerizos y cambios fusionados; reportar los rangos, no solo las medias, dado que se compara una ventana con muchas otras.
5. Seguir la tasa de segunda contribución durante los tres meses posteriores al evento y compararla con la de contribuyentes de código primerizos del mismo período.

Estado

No se afirma ningún resultado. Un solo evento no puede separar el efecto del día del de la convocatoria o el de la lista seleccionada; repetir el día con y sin la convocatoria, o anunciar la lista sin fijar un día, sería el siguiente paso si la primera comparación muestra un efecto.