From 2550dc7e510e4283eb1e8c884bb7c8c6b2c545c0 Mon Sep 17 00:00:00 2001 From: Shinya Maeda Date: Wed, 22 May 2019 02:27:34 +0000 Subject: Update code_review.md --- doc/development/code_review.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/doc/development/code_review.md b/doc/development/code_review.md index c4e5995714d..e845c98b641 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -13,8 +13,16 @@ You are strongly encouraged to get your code **reviewed** by a [reviewer](https://about.gitlab.com/handbook/engineering/workflow/code-review/#reviewer) as soon as there is any code to review, to get a second opinion on the chosen solution and implementation, and an extra pair of eyes looking for bugs, logic problems, or -uncovered edge cases. The reviewer can be from a different team, but it is -recommended to pick someone who knows the domain well. You can read more about the +uncovered edge cases. + +Usually, the reviewer should be someone who knows the domain well, +which is one of the team members corresponding to the feature label. For example, +if the merge request is labled ~Release, then you should pick one of [the team members](https://about.gitlab.com/handbook/engineering/ops/release/), +since they know about the functionalities better than the other team members, you'd be able to get more thoughtful opinions. +If you cannot find a relevant person or the merge request doesn't warrant a team label, you can ask one of the code owners for the review. +If you still cannot find a relevant person, please choose someone from [our dedicated reviewers](https://about.gitlab.com/handbook/engineering/projects/) + +You can read more about the importance of involving reviewer(s) in the section on the responsibility of the author below. If you need some guidance (e.g. it's your first merge request), feel free to ask -- cgit v1.2.1