Um dia agendado para documentação atrai mais contribuidores de primeira viagem do que um convite permanente para ajudar na documentação

Hipótese

As issues de documentação em projetos pequenos costumam ser pequenas, independentes e seguras para entregar a pessoas desconhecidas, e por isso recebem o rótulo good first issue. A documentação do GitHub inclui esse rótulo entre os padrões criados em todo repositório e o descreve como marca de issues adequadas a quem contribui pela primeira vez. Mesmo assim, essas issues podem ficar abertas por meses. A hipótese é que o ingrediente que falta não é a tarefa, e sim o momento: um dia fixo em que um mantenedor promete revisão no mesmo dia, as tarefas estão reunidas num só lugar com uma frase indicando por onde começar, e o convite é anunciado com uma semana de antecedência. Nesse dia, o custo de contribuir (a incerteza sobre se alguém vai olhar e se a tarefa ainda é desejada) é o menor possível, de modo que quem apenas observava faz a sua primeira alteração. A afirmação diz respeito especificamente a contribuidores de primeira viagem e a alterações integradas (merged), não ao volume de documentação escrita.

Previsão

Para um projeto que realiza um dia de documentação, o número de alterações de documentação integradas, de autoria de contribuidores de primeira viagem, nos sete dias em torno do evento é maior do que em qualquer outra janela de sete dias do ano anterior, e maior do que o total obtido pela mesma lista de issues durante os meses em que esteve aberta antes do evento. Previsão secundária: uma parte desses contribuidores faz uma segunda contribuição nos três meses seguintes, a uma taxa superior à dos contribuidores de código de primeira viagem do mesmo projeto.

Teste proposto

1. Preparar a lista: de oito a vinte issues de documentação, cada uma com a localização, uma definição de pronto e o rótulo good first issue, publicada duas semanas antes junto com a data e a promessa de revisão.
2. No dia, um mantenedor revisa apenas pull requests de documentação e responde em até uma hora durante o horário anunciado; nada mais muda no projeto.
3. Registrar, para cada alteração de documentação integrada nos doze meses anteriores e na janela do evento: autor, se foi a primeira contribuição do autor e o tempo entre o pull request e o merge.
4. Comparar a janela do evento com todas as outras janelas de sete dias do ano, quanto a autores de primeira viagem e alterações integradas; relatar as posições no ranking, e não apenas as médias, já que uma janela é comparada com muitas.
5. Acompanhar a taxa de segunda contribuição por três meses após o evento e compará-la com a dos contribuidores de código de primeira viagem do mesmo período.

Estado

Nenhum resultado é alegado. Um único evento não consegue separar o efeito do dia do efeito do anúncio ou da lista selecionada; se a primeira comparação mostrar algum efeito, o passo seguinte seria repetir o dia com e sem o anúncio, ou anunciar a lista sem um dia marcado.