From e554ad813af2e51606284cc628202919ba89d34c Mon Sep 17 00:00:00 2001
From: Maxime Dénès
Date: Wed, 21 Mar 2018 13:53:20 +0100
Subject: Refine a bit the decentralized merging process.

We make GitHub assign only principal maintainers as reviewers. This
reduces the level of noise (PRs with 10 code owners), and makes it easy
for the assignee to check if all reviews have been completed (all
reviewers in the list have to approve the PR, which was not the case
before if two reviewers were assigned for the same component).

This change means that when a principal maintainer submits a patch
touching the component they own, they should ask a review from the
secondary maintainer.
---
 dev/doc/MERGING.md | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

(limited to 'dev')

diff --git a/dev/doc/MERGING.md b/dev/doc/MERGING.md
index df366a9781..f1dddbd0ef 100644
--- a/dev/doc/MERGING.md
+++ b/dev/doc/MERGING.md
@@ -9,19 +9,23 @@ The [CODEOWNERS](/.github/CODEOWNERS) file describes, for each part of the
 system, two owners. One is the principal maintainer of the component, the other
 is the secondary maintainer.
 
-When a pull request is submitted, GitHub will automatically ask these two
-maintainers for a review. If the pull request touches several parts, all the
-corresponding maintainers will be asked for a review.
+When a pull request is submitted, GitHub will automatically ask the principal
+maintainer for a review. If the pull request touches several parts, all the
+corresponding principal maintainers will be asked for a review.
 
 Maintainers are never assigned as reviewer on their own PRs.
 
+If a principal maintainer submits a PR that changes the component they own, they
+must assign the secondary maintainer as reviewer. They should also do it if they
+know they are not available to do the review.
+
 ## Reviewing
 
-When principal maintainers receive a review request, they are expected to:
+When maintainers receive a review request, they are expected to:
 
 * Put their name in the assignee field, if they are in charge of the component
-  that is the main target of the patch (or if they are the only principal
-  maintainer asked to review the PR).
+  that is the main target of the patch (or if they are the only maintainer asked
+  to review the PR).
 * Review the PR, approve it or request changes.
 * If they are the assignee, check if all reviewers approved the PR. If not,
   regularly ping the author (if changes should be implemented) or the reviewers
-- 
cgit v1.2.3