Bug 分流指南¶ ↑

本指南讨论了在 Ruby 的 Bug 跟踪器中对 Bug 进行分流的建议。

具有可复现示例的 Bug¶ ↑

这些是最好的 Bug 报告。首先，考虑报告的 Bug 是否真的是问题，或者它是否是预期的 Ruby 行为。如果是预期的 Ruby 行为，请更新 Issue，说明为什么该行为是预期的，并将状态设置为“已拒绝”。

如果报告的 Bug 似乎是实际的 Bug，请尝试使用 master 分支复现该 Bug。如果您无法在 master 分支上复现该 Issue，请尝试在报告该 Bug 的分支的最新版本上复现它。如果您在这两种情况下都无法复现该 Issue，请更新 Issue，说明您无法复现该 Issue，询问报告者是否可以使用 master 分支或较新版本复现该 Issue，并将状态设置为“反馈”。

如果您可以在 master 分支上复现该示例，请尝试找出导致该 Issue 的原因。如果您觉得可以，请尝试为该 Issue 编写补丁，更新 Issue 并附加补丁。尝试找出应该将哪个提交者分配给该 Issue，将其设置为受让人，并将状态设置为“已分配”。

如果您无法在 master 分支上复现该示例，但可以在该分支的最新版本上复现该 Issue，则该 Bug 很可能已被修复，但尚未向后移植。尝试确定哪个提交修复了它，并更新 Issue，注明该 Issue 已被修复但尚未向后移植。如果 Ruby 版本处于安全维护阶段或不再受支持，请将状态更改为“已关闭”。此更改可以在不添加注释的情况下进行，以避免向邮件列表发送垃圾邮件。

对于可能需要向后不兼容的更改或可能受益于一般提交者关注或讨论的 Issue，请考虑将其作为下次提交者会议的议程项目 (bugs.ruby-lang.org/issues/14770)。

没有复现方法的崩溃 Bug¶ ↑

许多报告的 Bug 除了崩溃报告外几乎没有其他内容，通常无法复现该 Issue。这些 Bug 很难进行分流，因为它们通常不包含足够的信息。

对于这些 Bug，如果 Ruby 版本是 master 分支或该分支的最新版本，并且该分支处于正常维护阶段，请查看回溯，看看是否可以确定导致该 Issue 的原因。如果您可以猜测可能导致该 Issue 的原因，请看看是否可以整理出一个可复现的示例（这通常非常困难）。如果您无法猜测可能导致该 Issue 的原因，或者无法自己整理出一个可复现的示例，请要求报告者提供可复现的示例，并将状态更改为“反馈”。

如果 Ruby 版本不再是当前版本（例如，当 Ruby 2.5 分支上的最新版本为 2.5.5 时为 2.5.0），请在 Issue 中添加注释，要求报告者尝试该分支的最新 Ruby 版本并报告，并将状态更改为“反馈”。如果 Ruby 版本处于安全维护阶段或不再受支持，请将状态更改为“已关闭”。此更改可以在不添加注释的情况下进行。

带有第三方 C 扩展的崩溃 Bug¶ ↑

如果崩溃发生在第三方 C 扩展中，请尝试找出它发生在哪个 C 扩展中，并在 Issue 中添加注释，将该 Issue 报告给该 C 扩展，并将状态设置为“第三方问题”。

非 Bug 报告¶ ↑

Bug 跟踪器中任何不是问题报告的 Issue 都应将跟踪器从“Bug”更改为“功能”（新功能或性能改进）或“杂项”。此更改可以在不添加注释的情况下进行。

过时的 Issue¶ ↑

有许多 Issue 已经过时，几个月甚至几年都没有更新。对于处于“反馈”状态的过时 Issue，如果未收到反馈，您可以将状态更改为“已关闭”，而无需添加注释。对于处于“已分配”状态的过时 Issue，您可以联系受让人，看看他们是否可以更新该 Issue。如果受让人不再是活跃的提交者，请将其从受让人中删除并将状态更改为“打开”。