贡献者计划

把最投入的用户变成代码和内容贡献者，给清晰路径、认可和降摩擦。

为什么

贡献者以内部团队无法匹敌的成本产出功能、修 bug、写文档和翻译 — 健康的 OSS 相关项目 60%+ 非核心工作来自外部。贡献者路径也是转化最高的推荐源：贡献者带来雇主和人脉，因为他们投了声誉。认可（good-first-issue 标签、贡献者页、大会演讲邀请）是维持无酬工作的货币，且几乎不花你什么。没有计划，最愿帮忙的人撞上不可构建的仓库转而去贡献让这事变容易的竞品。

何时使用

有 5+ 用户反复答社区问题或提功能需求时。需求出现时才建计划，不提前。

如何做

1. 给 10-20 个 issue 打 'good-first-issue' 标签，带清晰验收标准和贡献指南链接
2. 写 CONTRIBUTING.md：环境搭建（一条命令）、测试命令、PR 清单、代码风格 — 验证新贡献者 30 分钟内能构建
3. 在文档加 'contributors' 页，从 all-contributors spec 或简单 git-log 脚本自动渲染
4. 24h 内初审收到的 PR 并评论，哪怕只"谢，本周审"— 沉默杀死贡献者动力
5. 建私 #contributors 频道让常驻讨论架构、早看路线图
6. 公开认可：每个合并 PR 发推、release notes 署名、邀请 top 3 去你的大会
7. 把反复贡献者升为维护者，先给子目录合并权，再给全仓
8. 追踪：月 PR 数、首次审查时间、贡献者留存（90 天内再 PR 了吗？）

示例

# CONTRIBUTING.md（要点）
## 搭建（一条命令）
make setup   # 装依赖、构建、跑测试

## 你的第一个 PR
1. 选带 'good-first-issue' 标签的 issue
2. 评论"我来"认领
3. 跑：make test（PR 前必须过）
4. 对 'main' 开 PR，填 PR 模板
5. 维护者 24h 内审查

# 认可循环
- 每个合并 PR → @ez4code 发推
- Release notes："感谢 @alice @bob 的 PR #123 #456"
- 季度：top 3 贡献者获大会演讲名额
- 年度：反复贡献者邀为维护者

# 指标
月 PR 数：12 → 28（6 个月后）
首次审查时间：3 天 → 18 小时
贡献者 90 天留存：22% → 51%

常见问题

⚠无 'good-first-issue' 标签，准贡献者找不到入口，对难题开 PR 后弃。
⚠搭建要 2 小时 4 个未文档步骤 — 80% 首次贡献者卡在构建步弃。
⚠PR 放一周不审；贡献者以为你不在乎再不回。
⚠只认可"大"PR，文档和测试贡献者 — 未来代码贡献者的管道 — 感觉无价值。

最佳实践

✓把搭建做成一条命令，验证全新贡献者 30 分钟内能构建测试；构建步摩擦杀死 80% 贡献。
✓24h 内对每个 PR 给人话评论；沉默是"贡献不被重视"的最响信号。
✓公开认可所有贡献类型（文档、测试、分诊）非仅代码 — 文档贡献者是未来代码贡献者。
✓把反复贡献者升为子目录合并权；所有权是留住资深贡献者的最强工具。