Skip to content

Latest commit

 

History

History
31 lines (30 loc) · 2.65 KB

review.md

File metadata and controls

31 lines (30 loc) · 2.65 KB
  • 开源最基本原则的体现,公开、透明
    • 如果连 review 都不做的话,何谈开源?要公开的绝不仅仅是结果,更关键的是要公开过程
    • review 绝对不是审核的意思,任何人都可以是 reviewer,大家都有可以在这个过程中有所收获
  • 生命周期
    • PR 不适用于有紧急合并需求的情况
    • 提交完 PR 后,作者首先应该自行检查一遍,如果发现还有问题的话,请标记为“进行中”
      • 我们可以把还没准备好 review 的 PR 的标题加上前缀:WIP:
      • 作者如果对某些代码(文档)不是很确定,可以直接把你的观点以评论的形式表述出来
    • 在 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 来阻止机器人账号自动合并