作为首次维护者的 Hacktoberfest

Source: Dev.to

请提供您想要翻译的文章正文内容，我将为您把它翻译成简体中文，并保持原有的 Markdown 格式、代码块和链接不变。谢谢！

Source: …

介绍

今年早些时候，我接手了 Cloudinary 的社区库 的维护工作。
几个月后，我的团队正准备参加 DigitalOcean 的年度 Hacktoberfest。

读者，我很担心。
我仍在熟悉这些库的工作方式并试图理清它们的 issue 积压。我从未参加过 Hacktoberfest，也听说过其他维护者关于每年大量垃圾 PR 的恐怖故事。

比雪崩更糟的是什么？是一场由最近 AI 生成代码工具爆炸式增长驱动的 涡轮雪崩。随着九月的结束，我想象着成百上千的 AI 编写的 PR 接踵而至——每个 PR 几百行代码，基于对底层问题理解不足的提示，包含提交者自己也不懂的代码，而我们却必须审阅它们。

好消息

情况并没有想象中那么糟。虽然 Hacktoberfest 的激励机制确实产生了一些垃圾（几乎所有的垃圾都像是 AI 生成的），但我们的团队通过强有力的政策提前解决了许多问题，如果再做一点准备和规划，还可以防止更多问题的出现。

• 最差的 PR 确实和我预期的一样糟糕，但数量没有我担心的那么多。
• 最好的 PR 可以说是 真的很棒。黑客马拉松的参与者解决了一些我已经拖了几个月的 issue，帮助库向前推进。

总体而言，作为维护者的参与耗费了大量时间（我们仍在讨论明年是否继续参与），但它也带来了实实在在的价值，并没有让我们不堪重负。希望它也帮助了一些贡献者在此过程中对开源的运作机制更加熟悉。

如果你正在考虑未来几年以维护者身份参与，继续阅读以了解哪些做法对我们有效——以及哪些无效。

成功之处

1. 将参与限制在特定的一组已有议题上

我们创建了一个 Hacktoberfest tag 并将其应用于精挑细选的议题列表。这解决了多个顾虑：

• 明确的任务 – 我们可以快速关闭任何随意、价值低的 PR（例如 “改进文档”）。
• 聚焦的工作 – 我们把 Hacktoberfest 的时间花在审查 PR 上，而不是重新提出新议题或定义新功能。
• 直接的修复 – 我们将贡献限制在修复相对简单的议题上，从而能够快速完成审查。

2. 预先设定配额

我们为本月结束前希望接受的贡献数量设定了目标，并为相应数量的议题打上标签。原因如下：

1. 成功度量 – 拥有可量化的目标可以让你清晰地传达成功或失败。我们依据 2024 年收到的成功提交数量来设定配额（见原始链接）。
2. 周边计划 – 我们为被接受的 PR 贡献者准备了一个 Cloudinary 的毛绒独角兽玩偶，因此需要提前知道需要准备多少个。

什么没有奏效

1. 过度标记的问题

我们对 Hacktoberfest 标签并不够“吝啬”。因为我们先设定配额，就在确认是否适合 Hacktoberfest之前就给大量 issue 打上了标签。结果：

• 我们花时间复现问题、说明新功能、审查复杂的 PR。
• 审核延迟变长，标签最终出现在我们只能模糊或不太了解的 issue 上，后来这些 issue “咬了我们”。

2. 期望不匹配

知道有配额的驱动让我去做一次完整的文档审查并提交了几条容易修复和审查的小 issue。虽然这有帮助，但也导致了：

• 如果没有 Hacktoberfest，我本不会进行文档审查。
• Hacktoberfest 的核心价值——让新人了解开源运作机制——被配额驱动的焦点稍微边缘化了。

3. 定义不清的 issue

一些被标记的 issue 定义不明确，导致出现尴尬的 PR。例子：

• 一位贡献者提交了一个“修复”，却与实际问题无关。该 issue 实际上在一年前已经作为更大更新的一部分被解决，但从未关闭。提交者可能把这个陈旧的 issue 输入到 AI 工具（如 Cursor），该工具尽力去解决一个已经解决的问题。

4. AI 生成的噪音

许多提交是借助 AI 完成的。这些 PR 背后的人类审阅者的理解程度参差不齐：

• 当贡献者理解问题和解决方案时，流程顺畅。
• 当理解不足时，后续的沟通（澄清问题或提出替代方案）往往无果，导致 PR 被关闭，双方都浪费了时间。

正面的惊喜

尽管面临挑战，最高质量的提交远远超出了我的预期。少数贡献者提交了深思熟虑、干净的 PR，帮助我们推动了库的前进。

经验教训与建议

1. 仔细筛选 Hacktoberfest 标签 – 只将其应用于你完全理解且真正适合快速、低风险修复的问题。
2. 设定切实可行的目标 – 与其设定固定配额，不如根据明确、符合标签条件的问题数量设定灵活目标。
3. 利用教育意义 – 鼓励新人学习开源工作流，即使他们的 PR 较小或需要迭代。
4. 为 AI 生成的提交做好准备 – 制定明确的政策来处理 AI 辅助的 PR，包括为审阅者提供评估意图和正确性的指南。
5. 事后规划周边和奖励 – 根据实际被接受的 PR 来估算周边需求，而不是预设配额。

结束语

作为维护者参与 Hacktoberfest 是一次挑战与回报交织的经历。通过更好的议题选择、更灵活的目标，以及关注新手的教育价值，未来的 Hacktoberfest 可以为维护者和贡献者带来更大的收益。

如果您考虑以维护者身份加入，请先 明确、狭窄的范围，提前沟通期望，并 拥抱社区的学习机会。祝 hacking 愉快！

对 Hacktoberfest 参与的反思

我 比以前更好地理解了底层框架，并抽出时间为我们尚未能够解决的细微问题提出深思熟虑的解决方案。我非常感激他们的时间和精力，这远比一只独角兽毛绒玩具和一件 Digital Ocean T‑恤更有价值。

由于一些问题相当棘手（而且我和其他技术审稿人在十月还有更多事务要处理，而不是审查 Hacktoberfest 的 PR），审查时间延长到了数周，我知道这让贡献者感到沮丧。在少数情况下，我们未能在 11 月 15 日截止日期 前接受或拒绝 PR。我们仍然给这些贡献者送去了独角兽，但如果 Hacktoberfest 的真正目的在于让人们熟悉开源的运作机制，而让他们了解到事情出乎意料地复杂且代码可能永远无法合并，这并不是一个很好的教训。再次强调，我希望我们在邀请人们解决哪些问题时能更谨慎一些。

Cloudinary 的成果

• 我们的社区库文档现在已经更加完善。
• 许多本可以拖延的小修复已经完成。
• 对几项我已拖延数月的重大问题取得了实质性进展。
• 希望参与者对 Cloudinary 及我们的 SDK 更加熟悉，并在继续发展职业生涯时更倾向于使用我们。

与此同时，缓慢（且在少数情况下仍未解决）的审查可能产生了相反的效果，导致参与者流失。对 Cloudinary 而言，时间成本是真实的，因为我们在十月和十一月将 Hacktoberfest 的工作优先于其他项目。

Personal Takeaway

个人而言，我真的很高兴我曾经做过一次。我们公司是否会决定明年再做一次还有待观察。

祝玩得开心！