本文由 CM 创始人 Steve Klabnik 发表在其个人博客上，分享了他在 GitHub 上为 Rails 开源项目所做的贡献和经验。这些经验和教训不仅对国内开源社区具有重要参考价值，特别是他提出的筛选问题的算法也非常实用。
CM 创始人：如何在 GitHub 上成为开源项目的守护者
作为一位长期从事开源工作的开发者，我认为我在开源领域最有价值的贡献并不是编写代码。尽管提交补丁是开源工作中最直接的部分，但实际上，其他所有开源任务都非常复杂，例如跟踪 Bug、管理邮件列表、编写文档和其他管理任务。本文将分享我在开源道路上学到的一些经验和教训。
让我们回到 RailsConf 2012 大会，当时作为与会者，我参加了一个小组讨论。那时，GitHub 上的 rails/rails 项目中有大约 800 个未解决的问题。会议的主要目标是减少这些问题的数量，并鼓励开源社区提供更多的帮助。最终，大家一致认为组建一个“问题处理团队”是最有效的解决方案，我也自愿加入了这个团队。
那么，“问题处理”具体指的是什么呢？在像 Rails 这样大型的项目中，许多小问题往往被忽视，有些问题最终被搁置，有些则需要更多的信息才能解决。通常，程序员不太愿意做这些“脏活累活”，因此项目需要一个“守护者”来定期清理这些问题。
在我们讨论如何清理这些问题之前，先了解一下我们面对的是什么样的“花园”。
这些问题（Issues）是什么？
如果你刚开始参与一个项目，首先需要明确问题的定义。对于不同的项目，问题的定义也会有所不同。例如，在 Rails 项目仓库中，我们主要关注 Bug 的修复，其他问题如功能请求和讨论则分别在 Stack Overflow 和邮件列表中处理。而在 Rust 项目仓库中，我们会在 Issues 中处理各种问题，包括功能请求和元问题。对于一些其他开源项目，解决所有问题可能是不现实的，有些项目甚至没有问题记录，如 Sequel。
我个人更倾向于 Rails 的问题处理方式。理想情况下，项目应该是无瑕疵的，功能讨论可以在专门的地方进行。但在实际操作中，提前规划好 Issues 是开源项目的第一步。
定期维护
那么，如何处理 800 多个问题呢？唯一的办法就是逐一审查。我通常会选择在周六或周日花一整天时间，进入 Issues 列表，右键点击每个问题，将其在新标签页中打开。我会一次打开 31 个标签页，其中 30 个是不同的问题，然后逐一阅读每个问题及其评论。完成一个页面后，关闭当前页面，继续处理下一个页面，直到所有问题都处理完毕。
虽然很多人认为开源工作充满魅力，但实际情况并非如此。为了做好开源工作，你需要牺牲自己的周末时间，仔细阅读每一个问题。
通过这种方式，我对 Rails 项目中常见的问题有了大致的了解。接下来，我需要再次重复这个过程。
为什么要再来一遍？因为在真正开始解决问题之前，面对如此多的问题，我可能会遇到许多重复的问题，不知道哪些评论是无关紧要的，也不知道哪些是常见的问题。因此，我开发了一个算法来高效处理这些问题：
1. 如果这是一个功能请求，复制/粘贴一个标准回答，引导用户到邮件列表中讨论，然后关闭问题。
2. 如果这是请求帮助的问题，复制/粘贴一个标准回答，引导用户到 Stack Overflow 寻求帮助，然后关闭问题。
3. 如果这是 Rails 旧版本的问题，而不是当前支持的版本，复制/粘贴一个标准回答，询问是否有人知道该问题是否仍然存在于当前版本。
4. 如果问题提供的信息不足以重现错误，复制/粘贴一个标准回答，询问是否有用户能提供错误重现的步骤。
5. 如果问题已经提供了错误重现的步骤，但问题并不出现在最新版本的 Rails 中，尝试 HEAD 请求，如果问题仍然存在，留下评论告知发布者问题依然存在。
6. 如果经过以上步骤，确定这是一个明确的问题，我会留下评论告知发布者我会处理，并将问题抄送给相关的子系统维护者，以便他们能够及时处理。
文章转载自 开源中国社区 [http://www.oschina.net]
京公网安备 11010802041100号