开源项目处理缺陷和修复的 5 个步骤

我做了很多开源工作，但我最有价值的贡献不是代码。编写补丁是开源项目中最容易的部分。真正困难的是其他所有事情：缺陷跟踪器、邮件列表、文档和其他管理任务。以下是我一路走来学到的一些东西。

那是 2012 年的 RailsConf 大会。我参加了一个小组讨论，会上提到了 rails/rails 上未解决问题的数量。当时大约有 800 个问题，并且已经持续了一段时间。有好奇的人想知道这个数字是否会下降，以及社区如何提供帮助。会上有人提出，有一个“问题团队”，他们的工作是分类问题。我热情地自愿加入了。

但是，“问题分类”到底意味着什么呢？ 嗯，对于像 Rails 这样的大型项目，有很多问题是不完整的、过时的、需要更多信息的……而且没有人去处理它们。这有点像花园：你需要有人拔草，并且经常和定期地拔草。

在我们讨论如何拔草之前，让我们先弄清楚我们手头到底有什么样的花园！

1. 问题是什么？

你的项目需要做的第一件事是弄清楚问题应该用于什么。每个项目都是不同的。例如，在 Rails 中，我们严格将问题仅用于缺陷。帮助问题转到 Stack Overflow，新功能讨论和请求转到 rails-core 邮件列表。对于 Rust，我们有用于功能请求、元问题... 等所有类型的问题。对于某些存储库，关闭所有问题是不可行的，而对于另一些存储库，你的目标是零。（如果你不相信这甚至是可能的，请查看 Sequel。问题很少会开放超过几天！）

我个人最喜欢的是遵循 Rails 的方式。理想情况下，你应该零缺陷，并且仍然有一个地方可以讨论功能。但实际上，有一个某种计划是必要的第一步。

2. 定期维护

那么你如何处理 800 个问题呢？我唯一知道的方法是：阅读所有问题。是的。这是我做的：我花了一个星期六（和一个星期天），然后去了 未解决问题列表，然后按住 Control 键单击每个问题，在新标签页中打开它们。最后，我还按住 Control 键单击了第 2 页。然后我关闭了这个标签页。现在我有 31 个打开的标签页：30 个问题，以及下一页。我通读了整个问题，包括评论。当我到达最后一个标签页时，我准备好重复这个过程：打开 30 个问题，打开第 3 页，点击关闭。下一个！

你看，人们认为从事开源工作很迷人，但实际上并非如此。从事开源工作是在一个周末阅读 800 个问题。

无论如何，一旦我阅读了所有这些问题，我就对 Rails 面临的各种问题有了更深入的了解。我有很多常见的问题、评论和难题。

3. 分类问题

下一步是再次执行所有操作。

等等，再次？为什么？ 嗯，既然我已经掌握了情况，我就可以实际承担起分类问题的任务了。如果我在获得背景知识之前尝试这样做，我可能看不到重复的问题，我不知道问题上通常有哪些类型的评论，我不知道维护人员在拉取请求中遇到的一些常见问题，总的来说，情况会更糟。

这一次，在阅读问题时，我经历了一个小算法来对它们进行分类。它看起来有点像这样

1. 这个问题是功能请求吗？ 如果是，复制/粘贴我写的一个答案，将其指向邮件列表，然后单击关闭。
2. 这个问题是请求帮助吗？ 如果是，复制/粘贴我写的一个答案，将其指向 StackOverflow，然后单击关闭。
3. 这个问题是针对比当前支持的 Rails 版本更旧的版本吗？ 如果是，复制/粘贴我写的一个答案，询问是否有人知道这是否会影响受支持的 Rails 版本。
4. 这个问题是否提供了足够的信息来重现错误？ 如果没有，复制/粘贴我写的一个答案，询问他们是否可以提供重现步骤。
5. 如果问题有重现步骤，并且它不是在最新的 Rails 上，请针对 HEAD 尝试一下。如果仍然发生，请留下评论，说明它仍然是一个问题。
6. 如果我们到了这一步，这个问题就相当可靠了。留下评论，说明我已经对其进行了分类，并抄送给 Rails 相关子系统的维护人员，以便他们可以找到与他们工作相关的问题。

在执行此操作的同时，我单击了 GitHub 界面上的这个按钮

然后设置了一个 Gmail 过滤器，将所有电子邮件过滤到它们自己的标签中，并跳过我的收件箱

我决定每天处理一页。这使得它更易于管理，而不是占用我整天的时间。我需要这些电子邮件和过滤器用于过程的重要的第二部分：定期维护花园。

4. 检查和过滤电子邮件

每天早上，在我上班之前，我会倒一杯咖啡并检查我的电子邮件。我不会在上班前处理所有邮件，但我努力首先处理 Rails 的邮件。通常每天早上会有大约 20 或 25 封新邮件，而且由于它基本上只是一条新评论，所以它们很快就能处理完。15 分钟后，我就又掌握了所有问题的最新情况。午餐时，我会再次这样做：十分钟处理午餐时的 10 封左右的电子邮件，然后在睡觉前，我会再次这样做：再花 15 分钟处理接下来的 20 条通知。基本上，我每天花费不到一个小时，但通过每天这样做，它永远不会失控。

一旦我处理完所有问题，我们就减少到更像是 600 个问题。四分之一的问题甚至根本不应该被打开。两周后，下一个大的收获开始了。为什么是两周？ 嗯，两周是我们决定的将问题标记为过时之前的宽限期。 为什么是两周？ 嗯，这有点随意，但两周感觉像是足够的时间让那些积极致力于解决问题的人做出回应。你看，问题通常需要报告者提供帮助才能真正解决，因为许多错误报告中没有足够的信息来重现和修复问题。

因此，两周后，我每天晚上又做了一件事：我按“最近更新最少”进行过滤，并检查是否有任何问题过时了。你只需回溯到它们显示“两周”为止，然后，如果你没有收到报告者的回复，请提及它已过时，并关闭问题。这是我在处理实际项目时不得不放下的另一件事之一：关闭问题不是永远的。

如果你发现自己错了，你总是可以稍后重新打开问题。因此，当试图处理 800 个未解决问题时，我默认“有罪推定”。以极大的偏见终止问题。留下旧的、没有结论的问题对任何人都没有帮助。如果这是一个对某人来说很重要的真正错误，他们会来帮助重现它。如果不是，也许其他人稍后会来。

在一个月或两个月后，坚持下去，我们将问题减少到 450 个左右。核心团队的成员开玩笑说，他们不得不为我设置额外的电子邮件过滤器，因为他们可以准确地判断出我何时在进行分类。慢而稳，方能致胜！

5. 编写补丁

在这一点上，我对 Rails 的了解足以真正开始编写一些补丁了。而且我碰巧熟悉基本上每个未解决的错误。因此，很容易开始选择其中一些并尝试在本地重现它们。所以我就会这样做，然后尝试编写补丁。如果我不能，我至少会上传我对这个问题的重现，然后在问题上留下注释，指向我的重现。这样，另一个团队成员只需克隆我的存储库即可开始处理。唯一比重现说明更好的是，当这些说明说 git clone 时。

但我设法提交了一些补丁，然后又提交了一些。完成所有这些清洁工作直接为获得 Rails 的提交权限铺平了道路。起初这是一个漫长的苦差事，但做得越多就越容易。开源中的很多工作都是这样：一旦你做了很多次，就很容易，但对新手来说却很难。我还不确定如何解决这个问题……

从那时起，我在我工作过的基本上每个存储库中都采用了这种方法，并且效果非常好。但它只有在你坚持下去时才有效：如果你不维护你的花园，你就会长杂草。在过去的几个月里，我没有那么多时间处理 Rails，现在它又回到了 800 个问题。我不确定这些是否是真正的问题，因为我已经停止维护了。但是，如果没有人积极关注，事情迟早会变得难看。如果你正在寻找帮助开源项目的方法，这不是一项光鲜亮丽的工作，但它只需要一点点努力，并养成一个习惯。

（哦，我应该花点时间提及 Code Triage。它超级有用，也可以帮助你找到需要帮助的项目。）

最初发布在 Steve Klabnik 的博客上。经许可转载。