Запланированный день документации привлекает больше новых контрибьюторов, чем постоянно висящий призыв помочь с документацией

Гипотеза

Задачи по документации в небольших проектах обычно маленькие, самодостаточные и не страшно доверить их незнакомому человеку — именно поэтому их помечают меткой good first issue; документация GitHub включает эту метку в список создаваемых по умолчанию в каждом репозитории и описывает её как отмечающую задачи, подходящие для тех, кто вносит вклад впервые. Тем не менее такие задачи могут висеть открытыми месяцами. Гипотеза состоит в том, что не хватает не самой задачи, а момента: фиксированного дня, в который мейнтейнер обещает ревью в тот же день, задачи собраны в одном месте с фразой о том, с чего начать, а приглашение анонсировано за неделю. В этот день издержки участия (неопределённость насчёт того, посмотрит ли кто-нибудь вообще и актуальна ли ещё задача) минимальны, поэтому люди, которые до этого только наблюдали, вносят свой первый вклад. Утверждение касается именно новых контрибьюторов и именно принятых изменений, а не общего объёма написанной документации.

Прогноз

Для проекта, который проводит день документации, число принятых изменений документации, авторами которых выступили новые контрибьюторы, за семь дней вокруг события выше, чем в любом другом семидневном окне предыдущего года, и выше, чем суммарно по тому же списку задач за месяцы, пока он висел открытым до события. Дополнительный прогноз: доля этих контрибьюторов делает второй вклад в течение следующих трёх месяцев, причём с более высокой частотой, чем у новых контрибьюторов кода того же проекта.

Предлагаемая проверка

1. Подготовить список: от восьми до двадцати задач по документации, у каждой указано место, определение готовности и метка good first issue; опубликовать за две недели вперёд вместе с датой и обещанием ревью.
2. В сам день один мейнтейнер рассматривает только pull request'ы с документацией и отвечает в течение часа в объявленные часы; больше в проекте ничего не меняется.
3. Фиксировать по каждому принятому изменению документации за предыдущие двенадцать месяцев и за окно события: автора, было ли это первым вкладом автора, время от подачи pull request до его принятия.
4. Сравнить окно события со всеми остальными семидневными окнами года по числу новых авторов и принятых изменений; приводить ранги, а не только средние значения, поскольку одно окно сравнивается со множеством других.
5. Отслеживать долю повторных вкладов в течение трёх месяцев после события и сравнить с новыми контрибьюторами кода за тот же период.

Статус

Никакой результат не утверждается. Одно-единственное событие не позволяет отделить эффект самого дня от эффекта анонса или отобранного списка задач; если первое сравнение покажет эффект, следующим шагом было бы повторить день с анонсом и без него либо анонсировать список без назначения дня.