Skip to content

Latest commit

 

History

History
49 lines (31 loc) · 2.12 KB

review.md

File metadata and controls

49 lines (31 loc) · 2.12 KB

Reviewing for BK-CI/BK-REPO

我们坚信code review所带来的价值:code review不仅可以提高质量、代码的可读性,同时也能不断提高开发者的水平, 促进开发者的编码能力,做出更好的设计。

以下是蓝鲸团队review issues和PRs/MRs的相关指引。

欢迎PRs/MRs

最重要的一条:欢迎在任何时候,反馈问题、反馈需求

提交前相关规范请审阅commit-spec

代码审查人员

Code review虽然会让特性与问题解决稍稍延后,同时也会造成额外审阅工作。因此蓝鲸团队希望积极参与项目相关人员也是 积极的审阅者,同时也期望相关的审阅者也具备相关领域的专业知识,以期提高处理效率。

审查细节

当PR/MR被提交之后,审查人员需要对该PR/MR进行快速分类,例如关闭重复,识别是否存在简单的用户错误,打上标签, 确认该PR/MR由哪些更具专业知识的审查人员进行review。

如果PR/MR被拒绝了,审查人员需要向发起者提供足够的信息反馈,解释为什么会被关闭。

在review的过程中,PR/MR的发起者请积极回答审查人员的疑问,进行评论。如有需要,对提交内容进行合理的调整。

审查人员在工作日内对于PR/MR处理要及时。在非工作日内,大家必须意识到,相关的处理会有所延时。

持有PR/MR

所有的参与人员不可能永远在处理相关的需求,如果审查人员因为时间关系没能立刻处理,建议在PR/MR的讨论中反馈处理时间。 对于PR/MR的作者,合理的做法是和审查人员积极磋商合理的deadline,或者是否有其他专业的审查人员可以处理,协商PR/MR 的交接。

合并

PR/MR达成以下标准时会被Merge:

  • 审查人员没有提出反对或者整改意见
  • 所有反对的建议或者调整的建议已经合理处理
  • 至少有一个分支的维护者赞成合入
  • 具备相关的文档和测试