分类 GitHub 问题
首先查看需要分类的 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 跟踪器的 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 并添加一条注释，说明“Duplicate of #issue”。通过遵循此约定，GitHub 将自动将该 Issue 标记为重复项。
评估影响
接下来，我们需要确定 Issue 的严重程度。
这是否是潜在的<强>发布阻碍者？
这些 Issue 应在一两周内解决，因为它们可能会阻止发布协调员发布干净的候选版本。
可能被标记为发布阻碍者的 Issue 可能是破坏我们预提交测试之一的回归问题。如果某个 Issue 已经存在一段时间（如果该 Issue 已经存在于一个或多个版本中，则根据定义它不能成为 RC 阻碍者），则避免将其标记为发布阻碍者。
这是否会导致应用程序<强>崩溃？
这些是导致 React Native 意外崩溃的 Issue。如果未能及早发现，这些可能会导致糟糕的用户体验。
这是一个<强>bug吗？
描述了某些未按预期工作的问题。在某个时候修复它会很好，但它不足以阻碍发布流程。即使该 Issue 导致崩溃，如果存在合理的解决方法，它也可以被归类为常规 bug。
这是一个<强>适合新手解决的 Issue吗？
这些 Issue 不需要对仓库有深入的理解和熟悉。GitHub 会将这些 Issue 展示给有兴趣成为贡献者的人。请记住，标记为此类别的 Issue 可能无法立即得到修复。