- 开源最基本原则的体现，公开、透明
- 如果连 review 都不做的话，何谈开源？要公开的绝不仅仅是结果，更关键的是要公开过程
- review 绝对不是审核的意思，任何人都可以是 reviewer，大家都有可以在这个过程中有所收获
- 生命周期
- PR 不适用于有紧急合并需求的情况
- 提交完 PR 后，作者首先应该自行检查一遍，如果发现还有问题的话，请标记为“进行中”
- 我们可以把还没准备好 review 的 PR 的标题加上前缀：
WIP: - 作者如果对某些代码（文档）不是很确定，可以直接把你的观点以评论的形式表述出来
- 我们可以把还没准备好 review 的 PR 的标题加上前缀：
- 在 2～7 天内完成 review 并合并
- 礼仪
- 没有人有义务对你的 PR 进行 review，包括维护者
- 每一位 reviewer 都对你的 PR 合并提供了帮助，对他们表示感谢
- 在最佳的 review 周期内，不要去催促任何人对你的 PR 进行 review
- 如果确实需要请求 review 帮助，请给出说明，并且优先 @ 某个 team，其次才是直接 @ 某个人，并对打扰表示歉意
- 明确你的观点
- 尽量避免给出模棱两可的评论，作者需要根据你给出的建议来决定是否要进行修改
- 对于你不是很确定问题，可以这么表述：”我感觉这里可能有问题，给出建议的做法以及理由，并指明该评论不阻碍 PR 的合并“
- 对于你很确定有问题的部分，给出可以证明你观点的信息或者数据，如果有相关权威资料的话，一并给出链接
- 例如：PR 中代码注释不规范，给出官方社区的文档链接
- reviewer
- 任何人都可以是 reviewer，只要是你认为有问题（或可以改进）的地方，都可以提出来，并且给出可以证明你观点的证据、资料链接
- 优先请求一个 team 帮忙 review，这样的话，你可以得到更多人的帮助
- 通常情况下，每一个文件都是由多名贡献者共同完善的，可以考虑让最后一次修改该文件的贡献者帮忙 review
- 如果你尝试解决的问题或者新增的特性来自另外一名贡献者创建的 issue，那也可以尝试寻求该贡献者的帮助
- 自动化流程
- 利用类似于 Lighthouse 的自动化工具来管理 review 流程
- 合并之前尽可能多地运行自动化测试（单元测试、e2e 测试、压力测试等）
- 避免人为干预自动化过程
- 如果 review 完成，但还需要一些人工验证的话，为避免过早自动合并，可以通过评论命令来阻碍
- 例如：通过评论
/hold来阻止机器人账号自动合并
- 例如：通过评论