flv 开源 修复

我们都在同一个团队中，并且都朝着使我们的开源软件变得更好的相同目标努力。 您的小贡献会产生重大影响。

开源软件的支持方式与运行方式同样重要。 如果选择构建令人敬畏的新功能，还是仔细阅读并响应10个错误报告，您会选择哪种呢？ 哪个更重要？ 当您想到开源维护者时，您会看到什么？ 我看到了问题。 我看到许多未解决的开放错误报告，几天之内都没有得到答复。 我看到一大堆功能请求正在等待处理。 现在，当我打开这些问题时，我看到维护人员会花费大部分时间来尝试获取所需的信息。 “您使用的是哪个版本？以前使用过吗？您能给我一个示例应用程序吗？”

您想让维护人员花时间询问微小的错误报告或解决问题吗？

当我想到开放源代码错误报告时，就会想到医院。 错误报告就像生病的病人走进急诊室。 没有人确切地知道他们需要什么才能变得更好。 他们有自我报告的症状，但需要更多信息。 当有人进入急诊室时，他们不会立即去找胸外科医师进行血压测量。 取而代之的是，他们去找一个记录自己生命的人，照顾好文书工作，然后确保为案件分配合适的医生。 医院将此过程称为“分类”，该过程来自法语，意思是“分离”。 这个人或团队不需要知道您到底出了什么问题，他们只需要知道医生将需要什么信息即可。 某人花在分诊上的每一分钟都是别人花在研究根本问题上的额外时间。

对于任何开源维护者来说，对错误进行分类都是一项必要技能，无论他们是在新建的库中工作还是在使用已有十年历史的框架中提供帮助。 这也是一项无需几年的编程知识就可以很快掌握的技能。 如果您想开始使用开源程序，但又担心自己还没准备好，那么分类是一个很好的第一步。

入门

首先，考虑使用的开源软件。 考虑一下语言，然后考虑您使用的任何开源库。 例如，如果您是Python程序员，则可以使用Django ， Requests库以及许多其他软件包 。 选择一些您认为非常受欢迎的东西。 这些项目拥有较大的团队，您将从中获得良好的经验。 但是，您还将希望选择一些较小的项目。 尽管您可能会因为一个较大的项目而迷失在人群中，但一个人却可以对一个较小的项目产生巨大的影响。

选择了一些库后，请找到它们的问题跟踪器。 当您能够花一些时间在开源上时，请尝试考虑一个好的触发器。 也许是每天早上喝咖啡，或者是在每周一次的团队口述之后，或者是您可以在每月一次的社区聚会之前利用时间。 我维护着一个开源项目，该项目将问题发送到您的收件箱CodeTriage 。 找到适合您生活的一致时间表和节奏。

当您坐下来进行分类时，要制定一个目标。 也许您想找到五个要评论的问题。 你到底该怎么说 问题有三种状态：

10）报告了一个错误。

20）收集了更多信息来重现该错误。

30）如果无法复制该错误，请转到20。

收集信息并迈向解决方案是您的工作。 让我们看看一些常见的问题类型以及可以帮助您解决的问题。

过时的问题

问题具有保质期。 如果他们没有积极地工作，它们可能会变坏。 也许原始报告者找到了解决方法，或者该错误自行解决了。

要查找问题，请在问题跟踪工具允许的情况下按“更新时间”排序。 浏览其中一些并发表评论：

您可以确认这仍然是问题吗？

如果问题确实很旧并且有人已经这样做了，则可以推动关闭不活动的问题：

最近两个月在这里没有活动，让我们暂时关闭此问题，然后在需要时重新打开。

对于从事此工作的人员来说，问题只是有益而有益的。 如果这个问题不够重要，原始报告人就不必关心，那么维护人员可能应该关注更多紧迫的问题。 解决问题不是最终决定。 如果问题再次出现，则可以重新打开该问题或由新问题引用。 通常，如果某个线程的持续时间太长，可能很难轻松地扫描所有对话，因此有时重新开始是前进的最佳方法。

回归分析

当程序正常运行但在版本更新不再有效时，这是一个回归 。 这些通常是作为维护人员最容易解决的错误。 通常，这些错误会说出“以前曾经工作过”之类的内容，但没有给出具体细节，您可以从中找到：

您现在使用什么版本？ 您工作之前使用的是哪个版本？

通常，这些报告将具有某种复制说明。 找到版本号后，请尝试重现该问题。 将时间设置为大约5或10分钟，这样您就不会花太多时间解决问题。 做笔记。 如果在重现问题时遇到任何问题或疑问，请写下来。 99％的报告将没有足够的信息来重现该错误。 对于记者来说，几乎不可能不打出该bug，因此它们将为您提供广泛的笔触，并希望您像他们一样打出该bug。 实际上，他们可能遇到压力大的情况，或者假设大多数其他人没有这样做。 您的工作是找到那个假设。

如果无法重现该问题，则有两种选择。 您可以报告有关如何尝试重现此问题以及如何不起作用的详细信息。 希望这会缓和记者的记忆，他们会指出您错过的关键一步。 第二个需要花费更多的时间，但从我的经验来看，从长远来看，它将节省每个人的时间：

您能否附上一个能够重现该问题的小型示例应用程序？

如果原始报告者使用最小的工件来创建新的存储库，即可再现问题，那么您可能仍需要与它们来回交互，但是操作会少很多。 如果他们不想制作一个示例应用程序，请告诉他们如何无法重现该问题，并提醒他们通常如果无法重现错误，则无法修复。 人们对开放源代码bug进行分类和修复的时间有限，因此他们可以更快地重现该问题，也可以更快地解决它。 如果问题对您来说很重要，那么要报告就足够重要，这意味着要加倍努力，并包括一个示例应用程序。

如果报告者已经包含一个应用程序，请尝试重现该问题，并报告该问题是否有效。 当维护人员看到问题并知道其他人重现了问题时，他们将知道他们也可以重现该问题。 听起来可能不多，但确实很有帮助。

信任但要验证

阅读错误报告有点像阅读一个不可靠的叙述者写的故事。 它们都表示很好，但是提交错误报告与对错误进行分类一样多。 您的工作的一半是对错误报告程序的培训和错误报告程序的培训。 同样，当您看到一个看起来像“通常的嫌疑犯”的报告来声明底层问题代码而无需验证时，这可能会很诱人。

当有人来解决错误时，我们希望他们有一个一致的叙述。 可以帮助获取此信息的一件事是与提交bug的人保持良好的融洽关系。 您可以感谢他们的时间和报告。 如果他们有关于分诊过程的后续问题，例如“为什么我在给您提供复制说明后到底要制作一个示例应用程序？”，请记住这可能是他们有史以来第一个打开的问题。 我们都在同一个团队中，并且朝着使我们的开源软件变得更好的相同目标而努力。 人类是软件的重要组成部分，它们都带有情感。 当每个人都保持头脑冷静和恭敬时，就是最大的成就。

拉取要求

拉取请求是附带解决方案的错误报告。 进行相同的动作。 确保您了解问题所在，如果没有链接问题，请索要复制案例。 另外，查看编码样式是否与项目的其余部分匹配。 PR是否附带测试或CHANGELOG？ 项目的每个新功能或错误修正必须具备哪些基本条件？

不是错误

人们经常会打开与该库无关的错误报告，或者具有记录良好的修复程序。 不用回答“ RTFM”，关闭并锁定问题的方法，而让自己陷入困境。 也许他们看到了文档，但感到困惑。 也许可以在其他地方记录下来？ 它不花任何代价就可以成为一个好人，并且将来可能会成为一个贡献者。

这是我在2012年发表的评论中的一个示例。 行为尚不清楚，所以我解释了为什么该软件可以正常工作。 我还链接到相关文档，并邀请他们提出后续问题。

每次解决问题时，您都应该问自己，为什么他们要解决这个问题？ 软件中存在许多技术上“非错误”的问题，这些问题因缺乏文档， 有意义的错误消息或正确编写的弃用而被掩盖。

有时会问一些问题，例如：“我想这样做，但不确定如何”。 这清楚地表明文档可能会更好。 如果您正在寻找简单的提交，那就只需要编写文档即可。 最好的故事是由经验丰富的人写的。 最好的文档是由用户编写的。 如果您没有时间添加文档，则可以留下一条注释，说明您认为应该进行文档更改的位置，然后要求报告者进行更改。 如果您的问题跟踪器很小，则可以打开一个新问题以指出文档更改。 通常，进行更改会更容易。

没事做

如果您发现一个活动的错误报告并且已经被复制，则可能无需执行任何操作。 大！ 寻找另一个问题或花时间阅读它们从错误报告到复制的过程。 其他维护者使用的主题或短语是否一致？ 也许他们有自己的技术来分类您可以使用的问题。

历史学家：代码，文化和约定

随着时间的流逝，您将越来越熟悉要分类的项目。 您将知道哪些维护者喜欢修复错误，并且可以预测哪个维护者会要求削减空白。 每个项目都有自己的约定。 例如，我已经与不接受任何重构，因为他们有能力惹项目合作blame 。 有些项目欢迎有问题的功能建议，有些则不欢迎，并要求进行讨论以转到邮件列表。 当您看到更多问题时，您将看到现有维护人员告诉提出问题的人员的内容。 随着时间的流逝，您会发现一个与上一个几乎相同的问题。 提供上下文对您有好处。 如果您知道其他维护者会要求您，则可以先占先占。

最终，您将开始看到错误或文档中的模式。 虽然您现在只注册分类问题，但是对于完善的错误修复和代码贡献来说，这是一个滑坡。 这是一件好事。 如果您已经知道其他维护者对您提出的问题或PR会说些什么，那么整个过程就不那么令人恐惧了。

从头开始

虽然本文篇幅较长，但核心思想很简单。 维护者时间很宝贵。 分类问题需要花费您一分钟的时间，并可以节省维护人员的时间。 分诊是一种您可以通过易于应用的常见模式学习的技能。 如果您仍在尝试从哪里开始，我建议返回您的库列表，找到它们或将其添加到CodeTriage并进行订阅。

为开源做贡献不必全职工作。 如果每个人都花一点钱，贡献就真的加起来了。 您的少量捐助可以产生重大影响。

翻译自: https://opensource.com/life/16/8/how-get-bugs-fixed-open-source-software

flv 开源 修复