Propose change to PR merging policy.

anntzer · anntzer · commit 1a8e0fc16479 · 2019-07-22T23:51:46.000+02:00
As discussed during the dev call.
diff --git a/doc/devel/coding_guide.rst b/doc/devel/coding_guide.rst
@@ -51,7 +51,7 @@ PR Review guidelines
   the threshold "is this better than it was?" as the review criteria.
 
 * For code changes (anything in ``src`` or ``lib``) at least two
-  developers (those with commit rights) should review all pull
+  core developers (those with commit rights) should review all pull
   requests.  If you are the first to review a PR and approve of the
   changes use the github `'approve review'
   <https://help.github.com/articles/reviewing-changes-in-pull-requests/>`__
@@ -63,7 +63,19 @@ PR Review guidelines
   :file:`doc/api/api_changes` and significant new features have and
   entry in :file:`doc/user/whats_new`.
 
-* Make sure the Travis, Appvyor, circle, and codecov tests are passing
+  - If a PR already has a positive review, a core developer (e.g. the first
+    reviewer, but not necessarily) may champion that PR for merging.  In order
+    to do so, they should ping all core devs both on github and on the dev
+    mailing list, and label the PR with the "Merge with single review?" label.
+    Other core devs can then either review the PR and merge or reject it, or
+    simply request that it gets a second review before being merged.  If no one
+    asks for such a second review within a week, the PR can then be merged on
+    the basis of that single review.
+
+    One core dev should only champion one PR at a time and we should try to
+    keep the flow of championed PRs reasonable.
+
+* Make sure the Travis, Appveyor, CircleCI, and codecov tests are passing
   before merging.
 
   - Whenever a pull request is created or updated, Travis and Appveyor
@@ -73,7 +85,7 @@ PR Review guidelines
 
 * Do not self merge, except for 'small' patches to un-break the CI or
   when another reviewer explicitly allows it (ex, "Approve modulo CI
-  passing, may self merge when green")
+  passing, may self merge when green").
 
 * Squashing is case-by-case.  The balance is between burden on the
   contributor, keeping a relatively clean history, and keeping a
@@ -94,8 +106,6 @@ PR Review guidelines
   with the contributor first.
 
 
-
-
 Branches and Backports
 ======================
 
