接收拉取请求的审核¶
您的拉取请求已提交并通过 CI。现在可以审核了。
tl;dr - 审查过程¶
审查过程简述：
- 等待审查。
- 回应反馈。
- 如果要求更改：
- 努力完成所要求的更改。
- 提交所有要求的更改。
- 提交所有要求的更改后，重新申请审查。
- 重复第三部分，直到无需进一步更改。
- 等待您的拉取请求被批准和合并。
恭喜您！您刚刚为 {{ 正式名称 }} 作出了贡献！
我提交了拉取请求，下一步该怎么做？¶
提交拉取请求后，您需要等待对您贡献的审核。审核过程有两个方面：提供审核和接收审核。
审阅预期
您应期望审核您提交的材料的任何人都遵守这些准则，包括核心团队成员的审核。在审核他人提交的材料时，您也应遵守这些准则。
如果您认为您的审稿人偏离了这些期望，并且您自己觉得可以在拉取请求中提出问题，您可以这样做。如果您觉得不方便，请联系BeeWare 行为准则响应团队。我们将审核您的报告，并与您的审核员进行跟进。跟进将反映所报告的行为；轻微的违规行为可能会导致讨论，而严重的违规行为可能会导致更严重的后果。
提供审查¶
欢迎所有人对任何拉取请求进行审核。本指南描述了我们对审核的期望，无论审核是由核心团队成员还是社区成员提供。
核心团队成员始终需要提供最终审核意见；但社区成员的审核意见可以帮助简化流程–理想情况下，在社区审核意见确定所有主要问题之后，核心团队的审核意见将流于形式。
接受审查¶
接受审查包括三个基本步骤：
- 初步反馈和问题。
- 更改请求。
- 批准和合并。
下面将详细介绍每个步骤。在此过程中，如果您有任何问题，请随时提出！我们很乐意提供帮助。
时间表和初步反馈¶
核心团队的目标是确保每个拉取请求都能在十个工作日内得到审核。不过，如果提交的请求比较复杂，或者提交请求时团队的部分成员正在休假，那么审核时间可能会延长。
我们通常会与每个拉取请求的审阅者保持连续性，也就是说，您可能会在整个审阅过程中与同一个审阅者合作。这意味着您的审核员在整个过程中都会有上下文，您也能了解到在响应节奏和审核风格方面的预期。如果您的初始审核员发现自己不具备审核您的拉取请求所需的专业知识，或者他们知道自己因为某些原因而无法审核您的拉取请求，他们可能会将您的拉取请求的责任移交给其他团队成员。
您可以期待我们在十个工作日的滚动时间内对每次交流做出回复。回复反馈和问题是审核流程的重要组成部分。我们希望您在我们进入下一步流程之前做出回复。
变更申请¶
大多数情况下，您的审核员会要求对您的拉取请求进行修改。这并不一定反映了您的工作，而只是流程的一部分。
如果初步审核发现了大量问题，那么第一次审核可能不会很全面。相反，它将专注于提供高水平的工作指导，使拉取请求进入可合并状态。审核过程中可能会提出一些问题，以澄清所尝试工作的目的和范围。
按要求进行修改¶
你的审核员会在你的拉取请求中发布注释。这些评论可以是一般性的，也可以是对某个文件或某行代码的评论。有时，他们会直接提出修改建议，您可以通过 GitHub UI 将其应用到您的拉取请求中。通常情况下，它们是问题、澄清请求或更新指导。
将对话标记为已解决
在反馈流程的讨论部分，您绝对不应该将审阅人发起的对话标记为 "已解决"。将对话标记为 "已解决 "是审阅人的责任。要由他们来决定所发现的问题是否已经解决。
如果审查发现了系统性问题（如代码中存在的命名不一致），审查员可能不会强调该问题的每个实例。相反，他们可能会挑出几个问题实例，并指出其他实例也应予以纠正。如果评审人员强调了某个地方的问题，而您认为该问题可能会在其他地方出现，那么您就应该在出现该问题的地方进行修正。如果您不确定，请向审核员询问。
提交所有要求的更改¶
一旦你完成了所有要求的修改，就可以推送更新到你的拉取请求。这将触发一次新的 CI 运行；一旦您确认 CI 仍然通过，请发表评论请求更新审核，核心团队将再次查看您的拉取请求。
推送，不要强制或rebase
当您在审核期间更新您的拉取请求时，保持提交历史的完整性非常重要。即使有一大串提交也没有关系，它们都会在我们合并拉取请求时被删除。如果您在审核过程中强行推送或重置您的拉取请求，您可能会删除审核员所需的重要上下文。
重新要求审查¶
一旦您解决了特定审核中的所有更改请求，并且 CI 再次通过，您就可以向审核员重新请求审核。如果问题特别复杂，修复一个问题会影响另一个问题，您可以要求对您更新的特定部分进行审核。我们的假设是，任何审阅请求都是对全面审阅的请求。如果您还没有准备好进行全面审核，请务必明确说明您需要的是什么。
拉取请求审批与合并¶
一旦您回复了所有变更请求，拉取请求就会被批准。在大多数情况下，一旦拉取请求获得批准，我们会立即将其合并。在某些情况下，可能会出现情有可原的情况，例如依赖于另一个尚未合并的拉取请求，从而导致延迟。我们会在评论中说明，以便您了解情况。