在 Hacktoberfest 期间维护开源软件

当我为 bulletty 的第一个可用版本做最后润色时，我注意到由 DigitalOcean 主办的年度活动 Hacktoberfest 即将到来，参与者通过在十月成功完成六个拉取请求（PR）即可获得T恤。我认为这是一个很好的机会来吸引社区参与，改进订阅阅读器，并提升项目的知名度。为此，我整理了 GitHub 上的问题区，为路线图上的每个功能和错误创建了单独的问题，添加了详细描述和图片。然后，我用“改进”、“错误”、“良好入门问题”和“Hacktoberfest”等标签进行了适当标记。起草了通用的 CONTRIBUTING 文件，概述了提交更改、报告错误和打开 PR 的流程。\n\n十月前几天，我在个人的 X、Bluesky 和 Mastodon 社交账号上推广该项目，并在 /r/hacktoberfest 子版块发布了帖子。发现官方 Hacktoberfest Discord 服务器后，我也在那里发布招募贡献者的信息。甚至尝试了 Hacker News，尽管反响最少。几天内，GitHub 的星标数接近一百，我在多个平台收到了大量回应，我认为这是一个良好的初步成功。\n\n然而，十月一开始，我很快就收到了许多贡献者请求分配问题，但没有任何事先讨论。这种做法显得过早且有风险，因为在不了解提议者计划的情况下分配问题可能会阻碍其他人贡献。因此，我更新了 CONTRIBUTING 文件，明确强调贡献者必须先就其预期实现进行讨论。只有在充分对话后，我才会分配问题。对于错误修复，只要贡献者详细说明更改内容，我允许提交 PR 而无需事先讨论。\n\n有一次特别的互动让我印象深刻，一位请求分配的用户提到了“知识”，这让我怀疑涉及某种 AI 辅助或“氛围编码”工作流程。确认后，我进一步修订了 CONTRIBUTING 指南，针对 AI 生成代码做出说明。我表示不会完全禁止 AI，但纯 AI 生成的 PR 不会被接受。贡献者必须披露 AI 使用情况，对提交负责，并准备接受严格的代码审查。未披露 AI 使用将被视为不诚实，导致 PR 被关闭。我分享了自己的观点，虽然我自己也使用 AI 工具，但将整个实现委托给 AI 而不真正理解是有问题的。\n\n当该用户提交的 PR 无法构建，尽管有明确指示仍缺乏适当格式，提交信息标题不当，且存在如更改方法名却未更新其 trait 定义等不一致情况时，这种怀疑得到了加强。这些迹象表明是自动代码生成尝试。我关闭了该 PR，并请求更有深度的贡献。此外，一些问题收到了模糊的“攻击计划”，看起来是 AI 生成且无意义，凸显了过滤低质量输入的挑战。\n\n回顾其他维护者的反馈，Hacktoberfest 经常吸引关注琐碎更改的垃圾 PR，如拼写错误修正或简单注释修改。随着先进 AI 模型能够重写大量代码，维护开源项目变得更加复杂。虽然 AI 可能处理简单任务表现良好，但大规模 AI 驱动的重构风险引入难以察觉的错误和模糊代码语义。与人类开发者不同，AI 缺乏彼得·瑙尔强调的软件作为“理论构建”的概念理解。此外，社区难以达成共识何为 AI 生成与人类工作，增加了管理难度。\n\n尽管存在这些挑战，Hacktoberfest 期间仍有有价值的贡献。在最初涌入的可疑 PR 之后，更积极的贡献者提交了有意义的改进。一个显著例子是为阅读器添加了前进和后退导航，这是之前缺失的关键功能。该实现还让我学习了 Rust 中 Rc 的引用计数用法，丰富了我的理解。\n\n总体而言，Hacktoberfest 带来了机遇与挑战。它促进了社区参与，加快了功能开发，但也引入了贡献质量相关的复杂性，尤其是 AI 辅助编码方面。清晰的沟通、严格的指南和细致的审查流程对于维护项目完整性至关重要。