2024年4月的某个周五晚11点，Maria 第127次刷新邮箱。屏幕亮了："Your initial application for Outreachy has been approved." 她截图、发推、给猫看。然后打开项目列表，大脑空白：现在呢？
这是 Outreachy 申请者的标准剧本。这个面向技术领域少数群体的实习项目，2024年收到超过 4,600 份初筛申请，最终录取约 150 人——录取率 3.2%，比哈佛 MBA 还低。
Maria 在获批第 5 天写下这些， panic 还新鲜到能尝出味道。她的时间线：4 月 15 日下午 4 点 UTC 截止，获批时只剩 26 天。听起来充裕？她后来发现，大多数人第一周都在"搞懂怎么贡献"上烧光时间。
Day 0：那封邮件之后，别急着写代码
获批当晚，Maria 的本能是冲进 issue 列表找个最难的 bug，证明自己配得上。她忍住了。
Outreachy 申请人指南（Outreachy Applicant Guide）有 30 多页，"又臭又长"——但回答了 90% 后来让她 panic 的问题。她设了一小时闹钟，硬读完了。
关键发现：需要至少一个"被接受的贡献"（accepted contribution）才有资格进入最终评选。不是"开始了"，不是"提交了"，是审核通过、合并或记录在案。这个区别让无数人倒在终点线前。
Maria 的 mentor 后来在 Matrix 频道说：「每周都有申请人问我'我提交了 PR 为什么没资格'——提交和接受是两件事。」
Day 1：选项目的陷阱
周六早晨。Maria 差点选了"安全牌"——一个她用过的工具链项目。理由是："我不是 AI 专家，Fedora AI 项目太冒险。"
她重新读了项目描述。Outreachy 的设计逻辑是帮助人学习新东西，mentor 评估的是学习能力，不是现有知识储备。她换了选择标准：不是"我会什么"，是"未来三个月我愿意每天琢磨这个吗？"
选定 Fedora AI 项目后，她做了一件 60% 申请者跳过的事：先加沟通频道，再碰代码。Fedora 用 Matrix，其他项目可能是 Slack、Zulip 或 IRC。
她的自我介绍模板：
"Hi everyone! I'm Maria, an Outreachy applicant interested in Fedora AI. I have experience with Python and machine learning basics, but I'm new to open source packaging. I read through the project description and I'm particularly curious about how we handle model versioning. Looking forward to learning from everyone!"
三小时后，mentor 回复了：「欢迎！模型版本控制正是我们头疼的点，可以先看 issue #847。」
第 3-5 天：贡献的隐藏规则
Maria 的第一个 PR 花了 4 天。不是代码难，是她没搞懂流程。
Outreachy 项目通常有"新手友好 issue"（good first issue）标签，但她发现：有些标了新手友好的 issue 其实需要深层上下文。她花了 6 小时在一个 issue 上，mentor 评论：「这个其实依赖另一个未合并的 PR，建议先放一放。」
她的调整策略：在频道里先问"这个 issue 当前状态如何"，再动手。节省的时间以天计算。
另一个坑：文档贡献算不算？Maria 的 mentor 明确说：「文档 PR 完全算数，但必须是实质性改进。改个错别字不算，重写一段让人困惑的教程算。」她最终提交了一个模型部署指南的补充章节，两次修改后被合并。
第 5 天晚上，Maria 在笔记本上写：「如果获批当晚有人告诉我这些，我能省出 4 天。」
她的最后一条记录是个问题，没写答案：「明年这时候，我会不会也忘了现在的 panic，给新人讲些没用的废话？」
热门跟贴