DOC: Clarify merge policy

doc/devel/pr_guide.rst

@@ -176,11 +176,22 @@ a corresponding branch.
 
 Merging
 -------
+As a guiding principle, we require two approvals from core developers before
+merging a pull request. This two-pairs-of-eyes strategy shall ensure a
+consistent project direction and prevent accidental mistakes. It's permissible
+to merge with one approval if the change is not fundamental and can easily be
+reverted any time in the future.
 
-* Documentation and examples may be merged by the first reviewer.  Use
+Some explicit rules following from this:
+
+* *Documentation and examples* may be merged by the first reviewer.  Use
   the threshold "is this better than it was?" as the review criteria.
 
-* For code changes (anything in ``src`` or ``lib``) at least two
+* Minor *infrastructure updates*, e.g. temporary pinning of broken dependencies
+  or small changes to the CI configuration, can be merged with a single
+  approval.
+
+* *Code changes* (anything in ``src`` or ``lib``) need at least two
   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'
@@ -205,9 +216,11 @@ Merging
     A core dev should only champion one PR at a time and we should try to keep
     the flow of championed PRs reasonable.
 
-* 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").
+After giving the last required approval, the author of the approval should
+merge the PR. PR authors must not self-merge, except for when another reviewer
+explicitly allows it (e.g., "Approve modulo CI passing, may self merge when
+green", or "Take or leave the comments. You may self merge".).
+Core developers may also self-merge in exceptional emergency situations.
 
 .. _pr-automated-tests: