DOC: tweak reviewer guidelines.

tacaswell · tacaswell · commit 668f260d3100 · 2018-07-15T01:32:11.000-05:00
- include link to Brett Cannon talk
 - re-order bullet points
diff --git a/doc/devel/coding_guide.rst b/doc/devel/coding_guide.rst
@@ -41,47 +41,53 @@ Documentation
 PR Review guidelines
 ====================
 
+* Be patient and `kind <https://youtu.be/tzFWz5fiVKU?t=49m30s>`__ with
+  contributors.
+
 * If you have commit rights, then you are trusted to use them.  Please
   help review and merge PRs!
 
-* For code changes (anything in ``src`` or ``lib``) two 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'
+* 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
+  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/>`__
   tool to mark it as such.  If you are a subsequent reviewer and you
   approve, either merge (and backport if needed) or select ``'approve
-  review'``.
+  review'`` if you think further review is required.
 
   Ensure that all API changes are documented in
   :file:`doc/api/api_changes` and significant new features have and
   entry in :file:`doc/user/whats_new`.
 
-* Documentation and examples may be merged by the first reviewer.  Use
-  the threshold "is this better than it was?" as the review criteria.
-
-* Make sure the Travis, Appvyor, and codecov tests are passing before
-  merging.
+* Make sure the Travis, Appvyor, circle, and codecov tests are passing
+  before merging.
 
   - Whenever a pull request is created or updated, Travis and Appveyor
     automatically runs the test suite on all versions of Python
     supported by Matplotlib.  The `tox` support in Matplotlib may be
     useful for testing locally.
 
-* Do not self merge, except for 'small' patches to un-break the CI.
+* 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")
 
 * Squashing is case-by-case.  The balance is between burden on the
   contributor, keeping a relatively clean history, and keeping a
   history usable for bisecting.  The only time we are really strict
   about it is to eliminate binary files (ex multiple test image
   re-generations) and to remove upstream merges.
 
-* Be patient with contributors.
-
 * Do not let perfect be the enemy of the good, particularly for
   documentation or example PRs.  If you find yourself making many
-  small suggestions, either open a PR against the original branch or
-  merge the PR and then open a new PR against upstream.
+  small suggestions, either open a PR against the original branch,
+  push changes to the contributor branch, or merge the PR and then
+  open a new PR against upstream.
+
+
 
 
 Branches and Backports
