分类 GitHub 问题
首先，查看需要分类的问题，这些问题通过 “Needs: Triage” 标签标识。
- 这是一个请求代码级别帮助的个人应用问题吗？它更适合 Stack Overflow 吗？如果是，请应用“Resolution: For Stack Overflow”标签。
- 此问题是否正确使用了模板？如果不是，请应用“Needs: Template”标签。
- 此问题是否提及了所使用的 React Native 版本？如果不是，请应用“Needs: Environment Info”标签。
- 此问题是否包含 Snack、代码示例或重现问题的步骤列表？如果不是，请应用“Needs: Repro”标签。
我们有时会收到不适合 GitHub 问题跟踪器的问题。添加“Type: Invalid”标签，机器人会自动关闭该问题。
到达此点后，您可以开始解析问题本身的内容。此问题是否包含问题的清晰描述？
如果没有，请礼貌地要求问题作者更新他们的 issue 并提供必要的信息，并应用“Needs: Author Feedback”标签。
我们的目标是始终友善和乐于助人，并期望我们社区的每一位成员都能做到这一点。
改进 Issue
如果问题包含所有必要信息，请花点时间考虑问题是否仍能以某种方式改进。格式是否正确？您可以根据需要轻微编辑问题以提高可读性。
如果问题包含未格式化的代码块，请用三个反引号（```）将其括起来，以将其转换为 markdown 代码块。
您是否可以添加任何标签以帮助更好地对其进行分类？如果问题只影响 Android 应用程序，您可以添加“Platform: Android”标签。也许问题只在 Windows 上开发时出现，在这种情况下，您可能会添加“Platform: Windows”标签。
我们有很长的标签列表，请查看是否有任何适用！
处理重复项
在处理这些问题的过程中，您将开始更好地了解所报告问题的类型。您甚至可能会开始注意到相同的问题被报告。
在这种情况下，您可以关闭问题并添加注释“Duplicate of #issue”。通过遵循此约定，GitHub 将自动将问题标记为重复项。
评估影响
接下来，我们需要确定问题的严重程度。
这是否是一个潜在的发布阻碍？
这些问题应在一到两周内解决，因为它们可能会阻止发布协调员发布干净的发布候选版本。
可能被标记为此类的问题可能是破坏我们预提交测试之一的回归。如果问题已经存在一段时间（如果问题已经存在于一个或多个版本中，根据定义它不能成为 RC 阻碍），则避免将问题标记为发布阻碍。
这是否会导致应用程序崩溃？
这些是导致 React Native 意外崩溃的问题。如果不及早发现，这些可能会导致糟糕的用户体验。
这是一个bug吗？
描述了未按预期工作的事情。在某个时候修复它会很好，但它不足以阻止发布列车。即使问题导致崩溃，如果有合理的解决方法，它也可以归类为常规错误。
这是一个适合新手的Issue吗？
这些问题不需要深入了解和熟悉仓库。GitHub 会将这些问题浮现给有兴趣成为贡献者的人。请记住，标记为此类的问题可能不会立即得到修复。