일정이 정해진 '문서화의 날'은 상시 모집보다 더 많은 첫 기여자를 데려온다

가설

소규모 프로젝트의 문서화 이슈는 대개 작고, 그 자체로 완결되어 있으며, 낯선 사람에게 맡기기에도 안전합니다. good first issue라는 라벨이 붙는 이유도 여기에 있습니다. GitHub 문서는 이 라벨을 모든 저장소에 기본으로 생성되는 라벨 중 하나로 소개하며, 처음 기여하는 사람에게 적합한 이슈를 표시하는 용도라고 설명합니다. 그런데도 이런 이슈는 몇 달씩 방치되곤 합니다. 이 가설이 제기하는 것은, 빠져 있는 요소가 작업 자체가 아니라 '시점'이라는 것입니다. 메인테이너가 당일 리뷰를 약속하는 정해진 하루, 어디서부터 시작하면 되는지 한 문장과 함께 한곳에 모아 둔 작업 목록, 그리고 일주일 전에 미리 알리는 초대. 그날은 기여의 비용(누군가 봐줄지, 그 작업이 여전히 필요한지에 대한 불확실성)이 가장 낮아지므로, 그동안 지켜보기만 하던 사람들이 첫 변경을 만들게 됩니다. 이 주장은 작성된 문서의 분량이 아니라, 첫 기여자와 머지된 변경에 관한 것입니다.

예측

문서화의 날을 실시하는 프로젝트의 경우, 행사를 전후한 7일 동안 첫 기여자가 작성해 머지된 문서화 변경 건수는 그 전 1년의 다른 어떤 7일 구간보다도 많고, 행사 이전에 같은 이슈 목록이 열려 있던 몇 달간의 합계보다도 많습니다. 부차적인 예측으로, 이 기여자들 중 일정 비율은 이후 3개월 안에 두 번째 기여를 하는데, 그 비율은 같은 프로젝트의 첫 코드 기여자보다 높습니다.

제안하는 검증

1. 목록을 준비합니다: 위치, 완료 기준, good first issue 라벨을 갖춘 문서화 이슈 8~20개를, 날짜 및 리뷰 약속과 함께 2주 전에 공지합니다.
2. 당일에는 메인테이너 한 명이 문서화 풀 리퀘스트만 리뷰하며, 공지된 시간 동안 한 시간 이내에 답합니다. 그 밖에 프로젝트에 대해 달라지는 것은 없습니다.
3. 지난 12개월과 행사 기간 동안 머지된 문서화 변경 건마다 다음을 기록합니다: 작성자, 그 작성자의 첫 기여였는지 여부, 풀 리퀘스트 생성부터 머지까지 걸린 시간.
4. 행사 기간을 그해의 다른 모든 7일 구간과, 첫 기여자 수와 머지된 변경 건수 기준으로 비교합니다. 하나의 구간을 여럿과 비교하는 것이므로 평균뿐 아니라 순위도 함께 보고합니다.
5. 행사 이후 3개월간의 두 번째 기여 비율을 추적하고, 같은 기간의 첫 코드 기여자와 비교합니다.

상태

어떠한 결과도 주장하지 않습니다. 단 한 번의 행사만으로는 '그날'의 효과와 '공지'의 효과, '엄선된 목록'의 효과를 분리할 수 없습니다. 첫 비교에서 효과가 나타난다면, 공지의 유무를 달리해 그날을 반복하거나, 그날 없이 목록만 공지해 보는 것이 다음 단계가 될 것입니다.