复习¶
本文档是Coala审查流程的指南。
我是否足够好来进行代码评审？¶
Yes, 如果您已经修复了新来者的问题。
复习可以帮助您理解表的另一边，并了解更多关于Coala和Python的知识。复习时，你会认识新的人，认识更多的代码，这最终会帮助你成为一名比你自己做得更好的程序员。
您完全可以帮助我们审查源代码。特别是试着复习别人的源代码，并与他们分享你所学到的东西。您可以像其他人一样使用ack和unack corobo 甚至允许您将PR设置为WIP。有关更多信息，请查看下面的部分。
通常遵循以下流程：
检查一下这些变化是否对我们有帮助。有时，人们提出的更改只对特定的用例有帮助，但可能会破坏其他用例。概念必须是好的。如果你不确定，可以考虑参与一场关于gitter的讨论！
检查自动生成。给投稿人一些提示，告诉他如何解决这些问题。
查看实际代码。提出改进和简化建议。
一定不要重数量轻质量！ 保持透明和礼貌：解释为什么某些事情必须改变，而不是无缘无故地“命令”程序员遵守准则。复查总是涉及到告诉某人他们的代码不正确，即使你不是故意的，也要非常小心不要显得粗鲁！不好的评论会吓跑其他贡献者。
备注
提交应该具有合适的大小，每个逻辑更改都应该是一次提交。如果有多个更改，则这些更改会进行多个提交。不要无缘无故地提议压制承诺！
在复查时，尽量做到彻底：如果您没有发现拉请求有任何问题，那么您很可能遗漏了一些东西。
如果您没有发现任何问题的拉取请求，并确认它，一个高级成员将检查它，并执行合并，如果一切都是好的。
审查讨论的最佳实践¶
公关评审后，除非进行了技术讨论，否则不要对评审发表评论，或者只有在与评审人员意见不一致的情况下才进行评论。对于有地址的状态，你可以竖起大拇指，避免评论像“谢谢”或“完成”这样的肯定。
手动审核流程¶
Coala的审查流程如下：
任何人都可以提交提交以供审查。这些是通过GitHub上的拉取请求提交的。
拉取请求将用一个
process标签：pending review提交刚刚被推送，正在等待审查wip拉式请求已标记为Work in Progress并对如何更改提交提出了意见approved开发人员已经对提交进行了审查，可以将它们合并到主分支中
如果您没有Coala的写入权限，可以使用更改标注
corobo mark wip <URL>或corobo mark pending <URL>.开发人员将以书面形式确认提交
如果成员正在审查它，请执行以下操作：
Looks good to me更广为人知的是LGTM以防提交准备就绪。
如果维护人员正在审查它，请执行以下操作：
ack commit_SHA或commit_SHA is ready，以防提交准备就绪，或者unack commit_SHA或commit_SHA needs work以防它还没有准备好，需要更多的工作或reack commit_SHA如果之前确认了提交，则在没有冲突的情况下重新基址，并且重新基址不会引入逻辑问题。
备注
每次提交只需要一个确认，即
ack commit_SHA.如果提交不能线性合并到主服务器中，则重新设置基址并转到第一步。
所有提交都会得到确认，并与主服务器线性匹配。所有持续集成服务(如下所述)均通过。维护人员可以离开
@gitmate-bot ff命令自动合并PR。
自动审核流程¶
只有在以下情况下才允许将拉式请求合并到master中 required GitHub状态为绿色。这包括GitMate审查以及持续集成系统。
连续集成总是针对拉式请求的最后一次提交进行的，但理想情况下应该在每次提交时都通过。
对于评论家来说¶
所有等待审查的拉取请求都可以在以下网址找到：https://coala.io/review.
检查提交消息。
阅读并尝试理解代码。如果某些内容看起来无效或容易出现错误，请留下评论。如果有疑问，让代码编写者在审查者理解代码之前解释他们的推理。
生成的代码不用于审查。相反，应该尝试验证生成过程是否正确。提交消息应该公开这一点。
每次提交都独立于其他提交进行审查。
每次提交都应该通过测试。如果您怀疑测试可能无法通过，并且持续集成没有检查提交，请尝试在本地运行测试。
检查一下周围环境。在许多情况下，人们在删除某物或类似物的使用时会忘记删除导入项。通常，最好查看整个文件，看看它是否仍然是一致的。
最后看看持续集成的结果，即使它们通过了。
覆盖率不能下降。
一定要确保测试覆盖了所有角落案例，并很好地验证了行为。例如，对于BEAR测试，仅测试好的和坏的文件是 not 足够了。 Writing Tests 解释应该如何编写测试。熊在测试过程中需要特别注意。 Testing Bears 提供了如何测试熊的指南。
确保PR中的更改没有从主分支机构推送过来。如果发生了这种情况，那么删除一条评论，告诉投稿人这不是一个好的做法，但也要指出投稿人不需要关闭特定的公关，应该从下一次开始注意这一点。
备注
在查看以下项目的拉取请求或修补程序时 difficulty/low 问题，请确保修补程序解决了问题，不会产生任何进一步的问题。
您需要彻底检查代码，即了解代码的功能，检查它是否有效，并留下批判性注释。否则，不要复习！我们需要人工审查来发现不能自动发现的问题。
当您审查每个提交时，请对GitHub拉取请求中的相关代码行进行注释。审核完成后，请直接对拉流请求进行评论，如下所示：
如果任何提交通过了审查，请进行以“ack”、“reack”或“Ready”(全部不区分大小写)开头的注释，并至少包含每个传递的提交散列的前6个字符，以空格、逗号或正斜杠分隔(来自GitHub的提交URL满足提交散列要求)。
如果任何提交未通过审查，请发表以“unack”或“neds work”(全部不区分大小写)开头的注释，并至少包含每个传递的提交散列的前6个字符，以空格、逗号或正斜杠分隔(来自GitHub的提交URL满足提交散列要求)。
备注
GitMate仅用空格和逗号分隔。如果您复制并粘贴SHA，它们有时包含制表符或其他空格，请务必删除它们！
例子：
unack 14e3ae1 823e363 342700d
如果您有大量的提交要确认，您可以使用以下命令轻松地生成一个列表 git log --oneline master.. 并编写一条消息，如下例所示：
reack
a8cde5b Docs: Clarify that users may have pyvenv
5a05253 Docs: Change Developer Tutorials -> Resources
c3acb62 Docs: Create a set of notes for development setup
Rebased on top of changes that are not affected by documentation
changes.
