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