与长期开放的文档协助召集相比，预先安排的文档日能带来更多首次贡献者

假设

小型项目中的文档类问题通常规模小、自成一体，可以放心交给陌生人处理，这正是它们被标记为 good first issue 的原因；GitHub 的文档将该标签列为每个仓库默认创建的标签之一，并将其描述为用于标记适合首次贡献者处理的问题。然而这类问题往往会挂起数月无人问津。本文的假设是：缺少的要素不是任务本身，而是时机——固定某一天，由维护者承诺当日评审，任务集中列在一处并附上从何入手的说明，且邀请提前一周发布。在这一天，参与贡献的成本（不确定是否有人会看、任务是否仍被需要）降到最低，于是原本只是观望的人便会做出他们的第一次改动。这一主张专门针对首次贡献者和已合并的改动而言，而非文档写作的总量。

预测

对于举办文档日的项目，活动前后七天内由首次贡献者撰写并合并的文档改动数量，会高于此前一年中任何其他七天窗口，也高于同一份问题清单在活动前开放的数月间所累积的总数。次要预测：这些贡献者中会有一部分人在此后三个月内做出第二次贡献，其比例高于该项目中首次贡献代码的贡献者。

建议的测试

1. 准备清单：列出 8 至 20 个文档问题，每个都注明位置、完成标准，并打上 good first issue 标签，提前两周连同日期和评审承诺一并发布。
2. 活动当天，由一名维护者只评审文档类拉取请求，并在公布的时段内一小时内回复；项目的其他方面不作任何改动。
3. 针对过去十二个月及活动窗口期内每一次已合并的文档改动，记录：作者、是否为该作者的首次贡献、从拉取请求提交到合并所用的时间。
4. 将活动窗口与该年中所有其他七天窗口在首次贡献者数量和已合并改动数量上进行比较；由于是以一个窗口对比众多窗口，应报告名次排位，而不仅仅是均值。
5. 追踪活动后三个月内的二次贡献率，并与同期首次贡献代码的贡献者相比较。

状态

本文未给出任何结果。单次活动无法将“当天效应”与“提前公告”或“精选清单”的效应区分开来；如果首次对比显示出效果，下一步应是在有无提前公告的情况下重复该活动日，或者只公布清单而不设定活动日。