GitHub Issues 的分类

首先查看需要分类的 issue，这些 issue 带有 "Needs: Triage" 标签。

这是一个关于个别应用的请求代码级帮助吗？这是否更适合在 Stack Overflow 上提问？如果是，应用 “Resolution: For Stack Overflow” 标签。
这个 issue 是否恰当地使用了模板？如果没有，应用 “Needs: Template” 标签。
这个 issue 是否提到了使用的 React Native 版本？如果没有，应用 “Needs: Environment Info” 标签。
这个 issue 是否包含 Snack、代码示例，或者重现问题的步骤列表？如果没有，应用 “Needs: Repro” 标签。

注意

我们有时会收到一些不太适合 GitHub issue 跟踪器的问题。添加 “Type: Invalid” 标签，一个机器人会自动关闭该 issue。

一旦你到了这一步，你可以开始解析 issue 本身的内容。这个 issue 是否包含对问题的清晰描述？

如果没有，礼貌地 要求 issue 作者使用必要的信息更新他们的 issue，并应用 “Needs: Author Feedback” 标签。

我们的目标始终是友好和乐于助人，并期望我们社区的每位成员都能做到这一点。

改进 Issue

如果 issue 包含所有必要的信息，请花一点时间考虑是否可以以某种方式改进 issue。格式是否正确？您可以根据需要轻轻编辑 issue 以提高可读性。

如果 issue 包含未格式化的代码块，请用三个反引号 (```) 将其包围，将其转换为 Markdown 代码块。

是否有任何标签可以添加以帮助更好地分类？如果 issue 仅影响 Android 应用，您可以添加 “Platform: Android” 标签。也许 issue 仅在 Windows 上开发时才会出现，在这种情况下，您可以添加 “Platform: Windows” 标签。

我们有一个很长的标签列表，请查看一下，看看是否有任何适用的标签！

当您处理这些 issue 时，您将开始更好地了解报告的问题类型。您甚至可能开始注意到同一个 issue 被多次报告。

在这些情况下，您可以关闭该 issue 并添加一条评论，内容为 “Duplicate of #issue”。通过遵循此约定，GitHub 将自动将该 issue 标记为重复项。

接下来，我们需要确定 issue 的严重程度。

这些 issue 应在一两周内解决，因为它们可能会阻止发布协调员剪切干净的候选发布版本。

可能被标记为此类问题的 issue 可能是破坏我们预提交测试之一的回归。如果一个 issue 已经存在一段时间（如果该 issue 已经存在于一个或多个版本中，则根据定义，它不可能是 RC 阻断问题），请避免将其标记为发布阻断问题。

这些 issue 会导致 React Native 意外崩溃。如果不尽早发现，这些问题可能会导致糟糕的用户体验。

描述的是某些东西未按预期工作。在某个时候修复它会很好，但它还不够严重，不会阻碍发布流程。即使 issue 导致崩溃，如果存在合理的解决方法，也可以将其归类为常规 bug。

这些 issue 不需要对仓库有深入的理解和熟悉。GitHub 会将这些 issue 展示给有兴趣成为贡献者的人。请记住，以这种方式标记的 issue 可能不会立即得到修复。