问题分级处理

BeeWare 会定期收到遇到问题的用户提交的问题报告。当收到新问题报告时，需要对报告进行triaged，也就是说，我们需要有人阅读报告，根据报告人提供的信息，尝试重现所描述的问题。

遗憾的是，尽管问题报告的初衷通常是好的，但它们往往不完整或令人困惑。分流流程的目的是填补原始报告的空白。这意味着要么生成足够的细节，以便我们能够确认如何重现问题；要么确认原始报告者的报告有误。

分流问题并不意味着你要修复它。根据问题的不同，分流甚至可能不需要编写代码。您只需对{{ 正式名称 }}}知之甚少就能分流问题，因为您应该能够按照报告中的步骤重现所描述的问题。

促进问题分流

重现该问题

如果首先没有问题，就无法解决问题。因此，重现问题是解决问题的前提。在软件中，问题通常被称为"错误"，而问题通常被称为 "错误报告"。

有人提供了一份错误报告。您需要验证报告者所描述的步骤是否导致了所报告的错误。你能否完全按照报告中的描述重现相同的结果？如果不能，就需要找出原因。

代码中的错误

在理想的情况下，您将拥有与报告错误者相同的设置，您将按照步骤操作，并且您将能够按照描述重现错误。但在很多情况下，这并不那么简单。许多错误报告只包含模糊的解释和一组模糊的条件。问题是，许多错误会根据所涉及的一系列条件而变化，包括与它们交互的方式、各种先决条件、操作系统、操作系统版本、CPU 架构，或者用户的机器是又老又慢还是又新又快。我们掌握的有关错误发生情况的信息越多越好。尝试重现报告者提供的一系列条件。如果无法重现，下一步可能需要向报告错误的人索取更多信息。

重现错误的最佳方法是使用尽可能小的示例，但仍能显示问题。大多数情况下，报告者不会提供最小可行的示例；如果他们提供了**示例，那也是直接从他们的 "现实世界 "应用程序中复制的。您的目标是将报告缩减到最简单的形式，以展示问题。最好的再现案例就是尽可能小的程序。这种还原本身就很有帮助，因为它能确定实际问题是什么。任何人都可以使用最小的示例，运行它，并观察到所描述的错误。

文件中的错误

文档中的错误有多种表现形式。有的是格式问题导致渲染问题。有时，这甚至不是一个错误；有关人员可能误读了文档，或者犯了一个真正的错误。这并不一定意味着文档没有问题。文档内容可能不清晰或不准确，给混淆或误解留下了空间。也有可能一个应该讨论的概念没有讨论，因为它完全没有文档记录。

当针对文档问题提交 bug 时，您需要验证所报告的问题是否仍然存在。如果是渲染问题，您需要构建文档，看看能否重现问题。内容问题则需要阅读以确认是否有人提交了更新。

更新问题

分流流程的最后一步是通过在问题上留下评论来记录您的发现。

如果您能完全按照描述重现问题，那就足够了。请留下评论，说明您已确认您看到了相同的问题，与原始报告者描述的方式完全一致。

如果您能够提供任何其他背景信息，那么请提供背景信息的详细信息。这可能包括能够在不同的操作系统上重现问题，或使用不同版本的相关软件，或任何其他与原始报告不同的内容。

如果原始报告中缺少您重现报告所需的细节，请将这些细节包括在内。这可能包括提供原始报告没有提供的操作系统或版本详细信息、更完整的日志或堆栈跟踪，或者更清晰地说明重现问题所需的确切操作顺序。如果您已经开发出一种更简单的方法来重现问题（或者原始报告者没有提供重现案例），您可以包含该重现方法的详细信息。

若您无法复现该问题，也请留言说明尝试过的操作。了解问题不存在的位置与存在的位置同样重要，这有助于缩小可能的成因范围。 若您对无法复现问题的原因有任何推测——例如认为是使用错误所致，或近期操作系统更新已解决该问题——请将这些推测纳入评论说明。

最后，您可以向核心团队提出任何建议。如果您认为原始报告有误，建议关闭该问题；如果您对问题的原因有自己的看法，也可以提出建议。您的意见将有助于核心团队确定如何将问题推进到下一步。