From a9b3f0811ae95e79e56abbfbfa8e0d1851a87b94 Mon Sep 17 00:00:00 2001 From: Dimitrie Hoekstra Date: Tue, 6 Nov 2018 08:23:14 +0000 Subject: Includes the way approvals are handled to the documentation --- doc/development/code_review.md | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/development/code_review.md') diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 3fe79943fdc..96f3861f8d7 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -23,6 +23,9 @@ one of the [Merge request coaches][team]. Depending on the areas your merge request touches, it must be **approved** by one or more [maintainers](https://about.gitlab.com/handbook/engineering/#maintainer): +For approvals, we use the approval functionality found in the merge request +widget. Reviewers can add their approval by [approving additionally](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#adding-or-removing-an-approval). + 1. If your merge request includes backend changes [^1], it must be **approved by a [backend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab-ce_maintainers_backend)**. 1. If your merge request includes frontend changes [^1], it must be @@ -97,6 +100,9 @@ If a developer who happens to also be a maintainer was involved in a merge reque as a domain expert and/or reviewer, it is recommended that they are not also picked as the maintainer to ultimately approve and merge it. +Maintainers should check before merging if the merge request is approved by the +required approvers. + ## Best practices ### Everyone -- cgit v1.2.1