我们都在同一个团队中，为了让我们的开源软件变得更好而共同努力。您的微小贡献会产生巨大的影响。
开源软件如何获得支持与它的运行效果同样重要。如果在构建令人惊叹的新功能与仔细阅读和回复 10 个错误报告之间做出选择，您会选择哪个？哪个更重要？当您想到开源维护者时，您会看到什么？我看到的是问题。我看到几十个未在数天内得到回复的未解决错误报告。我看到一堆等待处理的功能请求。现在，当我打开这些问题时，我看到维护者花费了大部分时间来获取他们需要的信息。“您使用的是哪个版本？之前工作正常吗？您能给我一个示例应用吗？”
您更希望维护者花费时间询问关于细微的错误报告，还是修复问题？
当我想起开源错误报告时，我会想到医院。错误报告就像一个病人走进急诊室。没有人确切知道他们需要什么才能好转。他们会自我报告症状，但还需要更多信息。当有人进入急诊室时，他们不会立即去找胸外科医生量血压。相反，他们会去找记录生命体征、处理文书工作，然后确保将合适的医生分配到该病例的人。医院将此过程称为“分诊”，这个词来自法语，意思是“分离出来”。这个人或团队不需要确切知道您有什么问题，他们只需要知道医生需要什么信息。分诊人员每花费一分钟，其他人就能多一分钟深入研究根本问题。
对于任何开源维护者来说，无论是处理新创建的库，还是帮助维护一个有 10 年历史的框架，错误分诊都是一项必要的技能。这也是一项可以相对快速掌握的技能，无需多年的编程知识。如果您想开始参与开源，但又担心自己还没准备好，那么分诊可能是一个很好的第一步。
入门
首先，考虑您使用的开源软件。想想编程语言，然后想想您使用的任何开源库。例如，如果您是一名 Python 程序员，您可能会使用 Django、Requests 库以及大量的其他软件包。选择一些您认为非常流行的。这些项目拥有更大的团队，您将从中获得良好的经验。但是，您还需要选择一些较小的项目。虽然您可能会在大型项目中迷失在人群中，但一个人可以在小型项目中产生巨大的影响。
一旦您选择了一些库，请找到它们的问题跟踪器。尝试考虑一个好的触发条件，让您能够花一些时间在开源上。也许是每天早上喝咖啡的时候，或者是在您每周一次的团队站会之后，或者您可以使用每月一次的社区聚会之前的时间。我维护一个开源项目，该项目会将问题发送到您的收件箱，CodeTriage。找到一个适合您生活的稳定计划和节奏。
当您坐下来进行分诊时，请设定一个目标。也许您想找到五个要评论的问题。您究竟应该说什么？问题有三种状态
10) 错误被报告。
20) 收集额外信息以重现错误。
30) 如果无法重现错误，则 GOTO 20。
您的工作是收集信息并朝着解决方案迈进。让我们看看一些常见的问题类型以及您可以做些什么来帮助解决。
过时的问题
问题有保质期。如果它们没有得到积极处理，它们可能会变坏。也许最初的报告者找到了解决方法，或者问题自行解决了。
要查找问题，如果问题跟踪器允许，请按“更新时间”排序。浏览其中的一些问题并留下评论
您能确认这仍然是一个问题吗？
如果问题真的很旧，并且有人已经这样做了，您可以推动关闭不活跃的问题
过去 2 个月这里没有任何活动，让我们现在关闭此问题，并在需要时重新打开。
问题的好坏和帮助程度取决于处理问题的人。如果这个问题对最初的报告者来说不够重要，那么维护者可能应该关注更紧迫的问题。关闭问题并不是最终的决定。如果问题再次出现，可以重新打开该问题或通过新问题引用它。通常，如果线程持续时间过长，则可能难以轻松扫描所有对话，因此有时重新开始是向前迈进的最佳方式。
回归
当程序之前运行正常，但在版本更新后不再运行时，这是一个回归。这些通常是维护者最容易处理的错误。通常这些错误报告会说“之前工作正常”，但没有给出具体细节，这时您就可以介入了
您现在使用的是什么版本？之前工作正常时您使用的是什么版本？
通常这些报告会包含某种重现说明。找到版本号后，尝试重现问题。将时间限制在 5 或 10 分钟左右，这样您就不会在问题上花费太多时间。做笔记。如果您在尝试重现问题时遇到任何问题或疑问，请记下来。99% 的报告不会包含足够的信息来重现错误。对于报告者来说，几乎不可能不遇到错误，因此他们会给您大范围的描述，并期望您像他们一样遇到错误。实际上，他们可能遇到了压力情况，或者做出了大多数其他人不会做的假设。您的工作是找到该假设。
如果您无法重现问题，您有两个选择。您可以报告详细信息，说明您如何尝试重现问题以及它如何不起作用。希望这能唤起报告者的记忆，他们会指出您遗漏的关键步骤。第二个选项会占用报告者更多的时间，但在我的经验中，从长远来看，这将节省大家的时间
请您附加一个可以重现问题的小型示例应用吗？
如果最初的报告者创建了一个新存储库，其中包含重现问题所需的最小工件，您可能仍然需要与他们进行一些来回沟通，但这将会少得多。如果他们不想制作示例应用，那么请告诉他们您无法重现问题，并提醒他们，通常如果无法重现错误，则无法修复。分诊和修复开源错误的人员时间有限，因此他们越快重现问题，他们就能越快修复问题。如果一个问题对您来说足够重要到需要报告，那么它就足够重要到需要好好报告，这意味着要付出额外的努力并包含一个示例应用。
如果报告者已经包含了一个应用，请尝试重现问题并报告它是否有效。当维护者看到问题并且他们知道其他人已经重现了问题时，他们就会知道他们也可以重现它。这听起来可能不算什么，但它真的很有帮助。
信任但要验证
阅读错误报告有点像阅读由不可靠的叙述者编写的故事。他们都出于好意，但提交错误报告与分诊错误一样是一项技能。您工作的一半是教育和指导错误报告者了解一个好的错误报告是什么样的。同样，当您看到一个看起来像“嫌疑犯”的报告时，很容易在未经验证的情况下声明底层问题代码。
当有人来研究修复错误时，我们希望他们有一个一致的叙述。与提交错误的人建立良好的关系可以帮助获得此信息。您可以感谢他们的时间和报告。如果他们对分诊过程有后续问题，例如“为什么我在给您重现说明后还必须制作示例应用？”，请记住，这可能是他们第一次打开问题。我们都在同一个团队中，为了让我们的开源软件变得更好而共同努力。人是软件的重要组成部分，他们都带有情感。当每个人都冷静和尊重时，才能完成最多的事情。
拉取请求
拉取请求是一个附带解决方案的错误报告。执行相同的步骤。确保您理解问题，如果没有链接的问题，请索要重现案例。此外，查看编码风格是否与项目的其余部分匹配。PR 是否附带测试或 CHANGELOG？每个新功能或错误修复项目都必须具备的基本要素是什么？
不是错误
人们经常会打开与库无关的错误报告，或者有充分记录的修复方案。与其回复“RTFM”、关闭并锁定问题，不如设身处地为他们着想。也许他们看到了文档，但感到困惑。也许可以将其记录在其他地方？友善对待您不会损失任何东西，并且可能会在未来赢得一位贡献者。
这是一个来自 我在 2012 年发表的评论的示例。行为不明确，因此我解释了软件的工作原理。我还链接到了相关文档，并邀请他们提出后续问题。
每次关闭问题时，您都应该问自己，他们为什么要打开这个问题？软件中存在许多技术上“不是错误”的问题，这些问题被缺乏文档、有意义的错误消息或正确编写的弃用警告所掩盖。
有时打开问题是为了提出问题，例如：“我想这样做，但我不确定如何做”。这清楚地表明文档可以做得更好。如果您正在寻找简单的提交，那么编写文档是不二之选。最好的故事是由经历过它们的人编写的。最好的文档是由用户编写的。如果您没有时间添加文档，您可以留下注释，说明您认为应该在哪里更改文档，并要求报告者进行更改。如果您的问题跟踪器很小，也许可以打开一个新问题来指出文档更改。通常，直接进行更改会更容易。
无事可做
如果您发现一个活跃的且已被重现的错误报告，您可能不需要做任何事情。太好了！查找另一个问题，或花时间阅读他们如何从错误报告到重现。维护者使用的主题或短语是否一致？也许他们有自己用于分诊问题的技术，您可以使用这些技术。
历史学家：代码、文化和约定
随着时间的推移，您将越来越熟悉您正在分诊的项目。您会知道哪些维护者喜欢修复错误，并且您将能够预测哪个维护者会要求修剪空格。每个项目都有自己的约定。例如，我曾参与过一些项目，这些项目不接受任何重构，因为它们会影响 blame 的能力。有些项目欢迎在问题中提出功能建议，有些项目则不欢迎，并要求讨论转到邮件列表。当您看到更多问题时，您将看到现有维护者告诉打开问题的人的内容。随着时间的推移，您会注意到一个几乎与之前的问题完全相同的问题。为您提供上下文是件好事。如果您知道另一个维护者会要求某些东西，您可以先发制人并首先要求它。
最终，您将开始看到错误或文档中的模式。虽然您现在只是注册进行问题分诊，但这很容易滑向全面的错误修复和代码贡献。这是一件好事。如果您已经知道其他维护者会对您打开的问题或 PR 说什么，那么这个过程就会变得不那么可怕了。
从头开始
虽然这篇文章有点长，但核心思想很简单。维护者的时间很宝贵。问题分诊占用您一分钟的时间，却可以节省维护者一分钟的时间。分诊是一项您可以通过可以轻松应用的常见模式来学习的技能。如果您仍然在努力寻找从哪里开始，我建议您回到您的库列表，找到它们或将它们添加到 CodeTriage 并订阅。
为开源做贡献不必是一份全职工作。如果每个人都贡献一点，那么贡献就会累积起来。您的微小贡献可以产生巨大的影响。
评论已关闭。