flv 开源 修复_解决开源项目错误和修复的5个步骤

flv 开源 修复

我在开源上做了很多工作，但是我最有价值的贡献不是代码。 编写补丁是开源最简单的部分。 剩下的全部才是真正困难的东西：错误跟踪器，邮件列表，文档和其他管理任务。 这是我在学习过程中学到的一些东西。

那是RailsConf2012。我参加了一次小组讨论，然后提出了有关rails / rails的问题。 当时大约有800期，已经有一段时间了。 询问者希望知道该数字是否会下降，以及社区如何提供帮助。 有人提出，有一个“问题小组”，其工作是对问题进行分类。 我热情地自愿。

但是，“问题分类”到底是什么意思 ？ 好吧，在一个与Rails一样大的项目中，存在大量不完整，陈旧，需要更多信息的问题……而且没有人照看。 有点像花园：您需要有人除草并经常定期除草。

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

1.有什么问题？

您的项目需要做的第一件事就是弄清楚应该解决什么问题 。 每个项目都是不同的。 例如，在Rails中，我们仅针对bug保留问题 。 帮助问题进入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分钟后，我又回到了所有问题上。 午餐时，我会再做一次：用十分钟来处理午餐时发送的大约十封电子邮件，然后，在上床睡觉之前，我会再做一次：再用15分钟来处理接下来的20条通知。 基本上，我每天只花不到一个小时的时间，但是每天都这样做，就永远不会失控。

一旦我解决了所有问题，我们的问题就减少到600多个。一开始就不应讨论整个问题的四分之一。 进入下一个重大收获的时间是两周。为什么要两周？ 好吧，两个星期是我们在将问题标记为陈旧之前决定的宽限期。 为什么要两个星期？ 好吧，这是任意的，但是如果某人对解决问题有积极的兴趣，那么两周的时间足以让他们做出回应。 看到，问题通常需要报告者的帮助才能真正解决，因为许多错误报告中没有足够的信息来重现和解决问题。

因此，两周后，每天晚上我又做一件事：我按“最近更新”进行过滤，并检查其中是否有过时的问题。 您只需回过头来，直到他们说“两个星期”，然后，如果您还没有收到记者的来信，请提一下这是陈旧的，然后就此问题进行解决。 在实际项目中，这是我不得不放手的其他事情之一：解决问题并非永远。

如果事实证明您错了，则以后可以随时重新打开问题。 因此，当试图处理800个未解决的问题时，我默认为“有罪，直到证明是无辜的”。 用极端的偏见来解决问题。 留下旧的，不确定的问题对任何人都没有帮助。 如果这是对某人重要的错误，那么他们会来帮助您重现它。 如果没有，也许以后还会有人。

一两个月之后，继续进行下去，我们得出了450个左右的问题。 核心团队的成员开玩笑说，他们必须向我设置额外的电子邮件过滤器，因为他们可以准确知道我何时进行分类。 踏实和稳重是赢得比赛的关键！

5.编写补丁

至此，我对Rails的了解足够多，可以真正开始编写一些补丁了。 而且我碰巧基本上熟悉每个打开的错误。 因此，很容易开始选择其中一些并尝试在本地复制它们。 所以我会这样做，然后尝试编写一个补丁。 如果不能，则至少上传问题的复制品，然后在问题上留下注释，指出我的复制品。 这样，另一个团队成员可以简单地克隆我的存储库并访问它。 唯一比复制指令更好的是当那些指令说git clone时 。

但是我设法得到了一些补丁，然后再添加了一些。 完成所有这些清洁工作直接引导了在Rails上实现提交的方式。 起初这是一个漫长的口号，但是我越做越容易。 这种方式在开源中进行了大量工作：完成很多工作确实很容易，但是对于新手来说很难。 我不确定如何解决这个问题...

从那以后，我基本上在我处理过的每个存储库上都采用了这种方法，并且效果很好。 但是，只有坚持下去，它才会起作用：如果您不照看花园，就会除草。 在过去的几个月中，我没有太多的时间在Rails上，而且又回到了800期。 我不确定这些是否是真正的问题，因为我已经不再照看。 但是，如果没有人积极关注，事情变得不合理只是时间问题。 如果您正在寻找一个开源项目的帮助，那可不是一件容易的事，但要做的只是一点点工作，养成习惯。

（哦，我在这里花点时间提及Code Triage 。它非常有用，并且还可以帮助您找到需要帮助的项目。）

最初发布在Steve Klabnik的博客上 。 经许可重新发布。

翻译自: https://opensource.com/business/14/5/how-be-open-source-gardener

flv 开源 修复