审查拉取请求

Bevy 社区活动非常活跃，审查他人的工作并提出改进意见，是你能做的最有价值的事情之一。

谁可以审查

任何人都可以！

你无需成为 Rustacean 资深人士才能发挥作用：任何人都可以发现遗漏的测试、不明确的文档、逻辑错误等等。如果你拥有特定技能（例如，对不安全代码的深入了解、渲染知识或 Web 开发经验）或对问题的个人经验，请优先考虑这些领域，以确保我们在需要时能获得合适的专业知识。

如果你发现自己不方便审查的 PR，但你能想到合适的人选，请考虑使用 GitHub 的“请求审查”功能（位于 PR 屏幕右上角）将工作提请他们注意。如果他们不是 Bevy 组织成员，你需要在主题中直接 ping 他们：这也是可以的！几乎所有在 Bevy 上工作的人都是志愿者；这应该被视为一种温和的提醒，而不是工作分配。考虑检查 Git 历史以查找合适的审阅者，或者在 Discord 上寻求建议。

如何审查拉取请求

如果你不熟悉 GitHub，官方网站上提供了大量关于拉取请求审查文档的信息。如果你对工作满意，并且认为自己有资格在该特定领域评估质量，请在 PR 上留下 Approved 审查。再次强调，任何人都可以并且应该留下审查 - 无需特殊权限！

提供反馈

专注于提供建设性的、可操作的反馈，这些反馈可以真正提高代码质量或最终用户体验。如果你不理解为什么采用了一种方法，请提问！

当有帮助时，提供实际的代码建议。小改动可以以评论或针对特定代码行的内联建议的形式进行。较大的更改应该在主主题中发表评论，或者是对原始作者分支的拉取请求（但请说明你已创建了一个）。当对架构理念存有疑问时，请参考我们的我们正在努力构建什么页面以获取指导。

即使你对 PR 的所有领域都没有百分之百的把握，也可以留下批准，但要确保指出你的局限性。当维护人员评估 PR 是否要合并时，他们会确保所有关键领域都得到了良好的覆盖。如果你只能检查数学是否正确，而另一个审阅者可以检查除数学之外的所有内容，我们就可以了！

同样，如果有些领域需要修复，但并不严重，请考虑留下批准。作者可以立即解决这些问题，或者将其分解成后续问题或 PR。大型 PR 对审阅者和作者来说都非常消耗精力，因此尽量推崇更小的范围，并清楚地跟踪后续工作。

请求更改

审查中要求进行额外更改是很常见的，但作为审阅者，尊重作者的时间很重要。

要求作者修复代码中的问题或错误，或要求他们以不同的方式做某事，都是可以接受的。要求额外的文档或测试也是可以的，但当这样做时，最好概述当前版本中缺少的内容。

否则，请尽量避免要求额外工作，除非绝对必要，尤其是当 PR 处于其他方面可接受的状态时。开源代码审查的目的是评估代码本身，而不是告诉作者该怎么做。

处理分歧

随着众多贡献者和审阅者共同构建一个复杂的系统，分歧不可避免地会出现。无论分歧是关于命名、性能还是代码覆盖率，目标都应该是在友好的氛围中达成共识。

牢记范围。推荐对周围区域进行简单的清理是可以的，但不要指望贡献者独自彻底改造 Bevy 的一部分。
不要害怕升级。无论你在审查过程中的哪个环节，如果你觉得有人不讲道理，请不要犹豫，联系其中一位维护人员或在 Discord 的相关开发频道发帖。
并非所有审查评论都会得到解决，这是正常的。你可以随时为进一步讨论打开一个问题。

审查内容

你可以从三个主要地方检查需要审查的内容

在 bevy 仓库中，准备就绪并需要更多审查的拉取请求。
在 bevy 和 bevy-website 仓库中的拉取请求。
RFC，需要社区对其设计进行深入思考和输入。

即使是我们的项目负责人和维护人员，也免不了审查和 RFC！通过对这些工作（以及相关的支持工作）提供反馈，你可以帮助我们确保我们的发布既高质量又及时。

最后，如果你最想看到的是所有问题都贴上了标签，所有已解决的问题都已关闭，请随时联系 @alice-i-cecile 或 @cart，获取 Bevy 组织的角色，帮助我们保持整洁。

正如我们在 Bevy 组织页面中所讨论的那样，这个角色只需要良好的意愿和对我们开发流程的基本了解。

拉取请求如何合并

维护人员在合并拉取请求时遵循以下规则

琐碎的 PR 可以由一位社区成员（包括维护人员）批准后合并。
相对无争议的 PR 可以由至少两位拥有适当专业知识的社区成员（包括维护人员）批准后合并。
有争议的 PR 除非获得项目负责人或两位主题专家（在 PR 所属的“领域”内）的批准，否则不能合并。
如果两位维护人员已批准有争议的 PR，他们可以通过将其添加到此队列中来“启动 PR 的计时器”。如果在 45 天内没有 SME 或项目负责人采取行动（批准、反馈或明确要求推迟），则维护人员可以合并 PR。