<divid="unreleased-message"> You are reading an old version of the documentation (v2.2.4). For the latest version see <ahref="https://matplotlib.org/stable/devel/coding_guide.html">https://matplotlib.org/stable/devel/coding_guide.html</a></div>
<spanid="reviewers-guide"></span><h1>Reviewers guideline<aclass="headerlink" href="#reviewers-guideline" title="Permalink to this headline">¶</a></h1>
<divclass="section" id="pull-request-checklist">
<spanid="id1"></span><h2>Pull request checklist<aclass="headerlink" href="#pull-request-checklist" title="Permalink to this headline">¶</a></h2>
<divclass="section" id="branch-selection">
<h3>Branch selection<aclass="headerlink" href="#branch-selection" title="Permalink to this headline">¶</a></h3>
<p>In general target the master branch for all new features and
bug-fixes. PRs may target maintenance or doc branches on
a case-by-case basis.</p>
</div>
<divclass="section" id="documentation">
<h3>Documentation<aclass="headerlink" href="#documentation" title="Permalink to this headline">¶</a></h3>
<ulclass="simple">
<li>Every new feature should be documented. If it's a new module, don't
forget to add a new rst file to the API docs.</li>
<li>Each high-level plotting function should have a small example in
the <codeclass="xref py py-obj docutils literal notranslate"><spanclass="pre">Example</span></code> section of the docstring. This should be as simple as
possible to demonstrate the method. More complex examples should go
in the <codeclass="xref py py-obj docutils literal notranslate"><spanclass="pre">examples</span></code> section of the documentation.</li>
<li>Build the docs and make sure all formatting warnings are addressed.</li>
<li>If you change the API in a backward-incompatible way, please
document it in <codeclass="file docutils literal notranslate"><spanclass="pre">doc/api/api_changes.rst</span></code>.</li>
</ul>
</div>
</div>
<divclass="section" id="pr-review-guidelines">
<h2>PR Review guidelines<aclass="headerlink" href="#pr-review-guidelines" title="Permalink to this headline">¶</a></h2>
<ul>
<li><pclass="first">Be patient and <aclass="reference external" href="https://youtu.be/tzFWz5fiVKU?t=49m30s">kind</a> with
contributors.</p>
</li>
<li><pclass="first">If you have commit rights, then you are trusted to use them. Please
help review and merge PRs!</p>
</li>
<li><pclass="first">Documentation and examples may be merged by the first reviewer. Use
the threshold "is this better than it was?" as the review criteria.</p>
</li>
<li><pclass="first">For code changes (anything in <codeclass="docutils literal notranslate"><spanclass="pre">src</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">lib</span></code>) 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 <aclass="reference external" href="https://help.github.com/articles/reviewing-changes-in-pull-requests/">'approve review'</a>
tool to mark it as such. If you are a subsequent reviewer please
approve the review and if you think no more review is needed, merge
the PR.</p>
<p>Ensure that all API changes are documented in
<codeclass="file docutils literal notranslate"><spanclass="pre">doc/api/api_changes</span></code> and significant new features have and
entry in <codeclass="file docutils literal notranslate"><spanclass="pre">doc/user/whats_new</span></code>.</p>
</li>
<li><pclass="first">Make sure the Travis, Appvyor, circle, and codecov tests are passing
before merging.</p>
<ulclass="simple">
<li>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 <codeclass="xref py py-obj docutils literal notranslate"><spanclass="pre">tox</span></code> support in Matplotlib may be
useful for testing locally.</li>
</ul>
</li>
<li><pclass="first">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")</p>
</li>
<li><pclass="first">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.</p>
</li>
<li><pclass="first">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,
push changes to the contributor branch, or merge the PR and then
open a new PR against upstream.</p>
</li>
<li><pclass="first">If you push to a contributor branch leave a comment explaining what
you did, ex "I took the liberty of pushing a small clean-up PR to
your branch, thanks for your work.". If you are going to make
substantial changes to the code or intent of the PR please check
with the contributor first.</p>
</li>
</ul>
</div>
<divclass="section" id="branches-and-backports">
<h2>Branches and Backports<aclass="headerlink" href="#branches-and-backports" title="Permalink to this headline">¶</a></h2>
<p>The current active branches are</p>
<dlclass="docutils">
<dt><em>master</em></dt>
<dd>This will be Matplotlib 3.0. Supports Python 3.5+.</dd>
<dt><em>v2.2.x</em></dt>
<dd>Maintenance branch for Matplotlib 2.2 LTS. Supports Python 2.7, 3.4+</dd>
<dt><em>v2.2.N-doc</em></dt>
<dd>Documentation for the current release. On a patch release, this will be replaced
by a properly named branch for the new release.</dd>
</dl>
<p>We always will backport to 2.2.x</p>
<ulclass="simple">
<li>critical bug fixes (segfault, failure to import, things that the
user can not work around)</li>
<li>fixes for regressions against 2.0 or 2.1</li>
</ul>
<p>Everything else (regressions against 1.x versions, bugs/api
inconsistencies the user can work around in their code) are on a
case-by-case basis, should be low-risk, and need someone to advocate
for and shepherd through the backport.</p>
<p>The only changes to be backported to 2.2.N-doc are changes to
<codeclass="docutils literal notranslate"><spanclass="pre">doc</span></code>, <codeclass="docutils literal notranslate"><spanclass="pre">examples</span></code>, or <codeclass="docutils literal notranslate"><spanclass="pre">tutorials</span></code>. Any changes to
<codeclass="docutils literal notranslate"><spanclass="pre">lib</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">src</span></code> should not be backported to this branch.</p>
<divclass="section" id="automated-backports">
<h3>Automated backports<aclass="headerlink" href="#automated-backports" title="Permalink to this headline">¶</a></h3>
<p>We use meeseeksdev bot to automatically backport merges to the correct
maintenance branch base on the milestone. To work properly the
milestone must be set before merging. If you have commit rights, the
bot can also be manually triggered after a merge by leaving a message
<codeclass="docutils literal notranslate"><spanclass="pre">@meeseeksdev</span><spanclass="pre">backport</span><spanclass="pre">to</span><spanclass="pre">BRANCH</span></code> on the PR. If there are conflicts
meeseekdevs will inform you that the backport needs to be done
manually.</p>
<p>The target branch is configured by putting <codeclass="docutils literal notranslate"><spanclass="pre">on-merge:</span><spanclass="pre">backport</span><spanclass="pre">to</span>
<spanclass="pre">TARGETBRANCH</span></code> in the milestone description on it's own line.</p>
<p>If the bot is not working as expected, please report issues to
<h3>Manual backports<aclass="headerlink" href="#manual-backports" title="Permalink to this headline">¶</a></h3>
<p>When doing backports please copy the form used by meeseekdev,
<codeclass="docutils literal notranslate"><spanclass="pre">Backport</span><spanclass="pre">PR</span><spanclass="pre">#XXXX:</span><spanclass="pre">TITLE</span><spanclass="pre">OF</span><spanclass="pre">PR</span></code>. If you need to manually resolve
conflicts make note of them and how you resolved them in the commit
message.</p>
<p>We do a backport from master to v2.2.x assuming:</p>
<ulclass="simple">
<li><codeclass="docutils literal notranslate"><spanclass="pre">matplotlib</span></code> is a read-only remote branch of the matplotlib/matplotlib repo</li>
</ul>
<p>The <codeclass="docutils literal notranslate"><spanclass="pre">TARGET_SHA</span></code> is the hash of the merge commit you would like to
backport. This can be read off of the github PR page (in the UI with
the merge notification) or through the git CLI tools.</p>
<p>Assuming that you already have a local branch <codeclass="docutils literal notranslate"><spanclass="pre">v2.2.x</span></code> (if not, then
<codeclass="docutils literal notranslate"><spanclass="pre">git</span><spanclass="pre">checkout</span><spanclass="pre">-b</span><spanclass="pre">v2.2.x</span></code>), and that your remote pointing to
<codeclass="docutils literal notranslate"><spanclass="pre">https://github.com/matplotlib/matplotlib</span></code> is called <codeclass="docutils literal notranslate"><spanclass="pre">upstream</span></code>:</p>
<spanclass="n">git</span><spanclass="n">checkout</span><spanclass="n">v2</span><spanclass="o">.</span><spanclass="mf">2.</span><spanclass="n">x</span><spanclass="c1"># or include -b if you don't already have this.</span>
<spanclass="c1"># resolve conflicts and commit if required</span>
</pre></div>
</div>
<p>Files with conflicts can be listed by <codeclass="xref py py-obj docutils literal notranslate"><spanclass="pre">git</span><spanclass="pre">status</span></code>,
and will have to be fixed by hand (search on <codeclass="docutils literal notranslate"><spanclass="pre">>>>>></span></code>). Once
the conflict is resolved, you will have to re-add the file(s) to the branch
<p>Use your discretion to push directly to upstream or to open a PR; be
sure to push or PR against the <codeclass="xref py py-obj docutils literal notranslate"><spanclass="pre">v2.2.x</span></code> upstream branch, not <codeclass="xref py py-obj docutils literal notranslate"><spanclass="pre">master</span></code>!</p>