<liclass="toctree-l2"><aclass="reference internal" href="MEP/MEP12.html">MEP12: Improve Gallery and Examples</a></li>
<liclass="toctree-l2"><aclass="reference internal" href="MEP/MEP13.html">MEP13: Use properties for Artists</a></li>
<liclass="toctree-l2"><aclass="reference internal" href="MEP/MEP14.html">MEP14: Text handling</a></li>
<liclass="toctree-l2"><aclass="reference internal" href="MEP/MEP15.html">MEP15: Fix axis autoscaling when limits are specified for one axis only</a></li>
<li><p>Formatting should follow the recommendations of <aclass="reference external" href="https://www.python.org/dev/peps/pep-0008/">PEP8</a>, as enforced by
<aclass="reference external" href="https://flake8.pycqa.org/">flake8</a>. Matplotlib modifies PEP8 to extend the maximum line length to 88
characters. You can check flake8 compliance from the command line with</p>
<p>or your editor may provide integration with it. Note that Matplotlib
intentionally does not use the <aclass="reference external" href="https://black.readthedocs.io/">black</a> auto-formatter (<aclass="reference external" href="https://github.com/matplotlib/matplotlib/issues/18796">1</a>), in particular due
to its inability to understand the semantics of mathematical expressions
<li><p>All public methods should have informative docstrings with sample usage when
appropriate. Use the <aclass="reference internal" href="document.html#writing-docstrings"><spanclass="std std-ref">docstring standards</span></a>.</p></li>
<li><p>For high-level plotting functions, consider adding a simple example either in
the <codeclass="docutils literal notranslate"><spanclass="pre">Example</span></code> section of the docstring or the
<p>In general, Matplotlib modules should <strong>not</strong> import <aclass="reference internal" href="../api/matplotlib_configuration_api.html#matplotlib.rcParams" title="matplotlib.rcParams"><codeclass="xref py py-obj docutils literal notranslate"><spanclass="pre">rcParams</span></code></a> using <codeclass="docutils literal notranslate"><spanclass="pre">from</span>
<spanclass="pre">matplotlib</span><spanclass="pre">import</span><spanclass="pre">rcParams</span></code>, but rather access it as <codeclass="docutils literal notranslate"><spanclass="pre">mpl.rcParams</span></code>. This
is because some modules are imported very early, before the <aclass="reference internal" href="../api/matplotlib_configuration_api.html#matplotlib.rcParams" title="matplotlib.rcParams"><codeclass="xref py py-obj docutils literal notranslate"><spanclass="pre">rcParams</span></code></a>
singleton is constructed.</p>
</li>
<li><p>If your change is a major new feature, add an entry to the <codeclass="docutils literal notranslate"><spanclass="pre">What's</span><spanclass="pre">new</span></code>
section by adding a new file in <codeclass="docutils literal notranslate"><spanclass="pre">doc/users/next_whats_new</span></code> (see
<codeclass="file docutils literal notranslate"><spanclass="pre">doc/users/next_whats_new/README.rst</span></code> for more information).</p></li>
<li><p>If you change the API in a backward-incompatible way, please document it in
<codeclass="file docutils literal notranslate"><spanclass="pre">doc/api/next_api_changes/behavior</span></code>, by adding a new file with the
naming convention <codeclass="docutils literal notranslate"><spanclass="pre">99999-ABC.rst</span></code> where the pull request number is followed
by the contributor's initials. (see <codeclass="file docutils literal notranslate"><spanclass="pre">doc/api/api_changes.rst</span></code> for more
information)</p></li>
<li><p>If you add new public API or change public API, update or add the
corresponding type hints. Most often this is found in the corresponding
<codeclass="docutils literal notranslate"><spanclass="pre">.pyi</span></code> file for the <codeclass="docutils literal notranslate"><spanclass="pre">.py</span></code> file which was edited. Changes in <codeclass="docutils literal notranslate"><spanclass="pre">pyplot.py</span></code>
are type hinted inline.</p></li>
<li><p>See below for additional points about <aclass="reference internal" href="contribute.html#keyword-argument-processing"><spanclass="std std-ref">Keyword argument processing</span></a>, if
applicable for your pull request.</p></li>
</ul>
<divclass="admonition note">
<pclass="admonition-title">Note</p>
<p>The current state of the Matplotlib code base is not compliant with all
of these guidelines, but we expect that enforcing these constraints on all
new contributions will move the overall code base quality in the right
<h2>Summary for pull request authors<aclass="headerlink" href="#summary-for-pull-request-authors" title="Link to this heading">#</a></h2>
<divclass="admonition note">
<pclass="admonition-title">Note</p>
<ulclass="simple">
<li><p>We value contributions from people with all levels of experience. In
particular if this is your first PR not everything has to be perfect.
We'll guide you through the PR process.</p></li>
<li><p>Nevertheless, please try to follow the guidelines below as well as you can to
help make the PR process quick and smooth.</p></li>
<li><p>Be patient with reviewers. We try our best to respond quickly, but we
have limited bandwidth. If there is no feedback within a couple of days,
please ping us by posting a comment to your PR.</p></li>
</ul>
</div>
<p>When making a PR, pay attention to:</p>
<ulclass="checklist">
<li><p><aclass="reference internal" href="#pr-branch-selection"><spanclass="std std-ref">Target the main branch</span></a>.</p></li>
<li><p>Adhere to the <aclass="reference internal" href="contribute.html#coding-guidelines"><spanclass="std std-ref">Coding guidelines</span></a>.</p></li>
<li><p>Update the <aclass="reference internal" href="#pr-documentation"><spanclass="std std-ref">documentation</span></a> if necessary.</p></li>
<li><p>Aim at making the PR as "ready-to-go" as you can. This helps to speed up
the review process.</p></li>
<li><p>It is ok to open incomplete or work-in-progress PRs if you need help or
feedback from the developers. You may mark these as
<p>See also <aclass="reference internal" href="contribute.html#contributing"><spanclass="std std-ref">Contribute</span></a> for how to make a PR.</p>
</section>
<sectionid="summary-for-pull-request-reviewers">
<h2>Summary for pull request reviewers<aclass="headerlink" href="#summary-for-pull-request-reviewers" title="Link to this heading">#</a></h2>
<divclass="admonition note">
<pclass="admonition-title">Note</p>
<ulclass="simple">
<li><p>If you have commit rights, then you are trusted to use them.
<strong>Please help review and merge PRs!</strong></p></li>
<li><p>Be patient and <aclass="reference external" href="https://youtu.be/tzFWz5fiVKU?t=49m30s">kind</a> with
contributors.</p></li>
</ul>
</div>
<p>Content topics:</p>
<ulclass="checklist simple">
<li><p>Is the feature / bugfix reasonable?</p></li>
<li><p>Does the PR conform with the <aclass="reference internal" href="contribute.html#coding-guidelines"><spanclass="std std-ref">Coding guidelines</span></a>?</p></li>
<li><p>Is the <aclass="reference internal" href="#pr-documentation"><spanclass="std std-ref">documentation</span></a> (docstrings, examples,
what's new, API changes) updated?</p></li>
<li><p>Is the change purely stylistic? Generally, such changes are discouraged when
not part of other non-stylistic work because it obscures the git history of
functional changes to the code. Reflowing a method or docstring as part of a
larger refactor/rewrite is acceptable.</p></li>
</ul>
<p>Organizational topics:</p>
<ulclass="checklist simple">
<li><p>Make sure all <aclass="reference internal" href="#pr-automated-tests"><spanclass="std std-ref">automated tests</span></a> pass.</p></li>
<li><p>The PR should <aclass="reference internal" href="#pr-branch-selection"><spanclass="std std-ref">target the main branch</span></a>.</p></li>
<li><p>Tag with descriptive <aclass="reference internal" href="#pr-labels"><spanclass="std std-ref">labels</span></a>.</p></li>
<li><p>Set the <aclass="reference internal" href="#pr-milestones"><spanclass="std std-ref">milestone</span></a>.</p></li>
<li><p>Keep an eye on the <aclass="reference internal" href="#pr-squashing"><spanclass="std std-ref">number of commits</span></a>.</p></li>
<li><p>Approve if all of the above topics are handled.</p></li>
<li><p><aclass="reference internal" href="#pr-merging"><spanclass="std std-ref">Merge</span></a> if a sufficient number of approvals is reached.</p></li>
</ul>
</section>
<sectionid="detailed-guidelines">
<spanid="pr-guidelines-details"></span><h2>Detailed guidelines<aclass="headerlink" href="#detailed-guidelines" title="Link to this heading">#</a></h2>
<sectionid="documentation">
<spanid="pr-documentation"></span><h3>Documentation<aclass="headerlink" href="#documentation" title="Link to this heading">#</a></h3>
<ulclass="simple">
<li><p>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.</p></li>
<li><p>Each high-level plotting function should have a small example in
the <codeclass="docutils literal notranslate"><spanclass="pre">Examples</span></code> section of the docstring. This should be as simple as
possible to demonstrate the method. More complex examples should go into
a dedicated example file in the <codeclass="file docutils literal notranslate"><spanclass="pre">examples</span></code> directory, which will be
rendered to the examples gallery in the documentation.</p></li>
<li><p>Build the docs and make sure all formatting warnings are addressed.</p></li>
<spanid="release-notes"></span><h4>New features and API changes<aclass="headerlink" href="#new-features-and-api-changes" title="Link to this heading">#</a></h4>
<p>When adding a major new feature or changing the API in a backward incompatible
way, please document it by including a versioning directive in the docstring
and adding an entry to the folder for either the what's new or API change notes.</p>
<tableclass="table">
<thead>
<trclass="row-odd"><thclass="head"><p>for this addition</p></th>
<thclass="head"><p>include this directive</p></th>
<thclass="head"><p>create entry in this folder</p></th>
<p>If multiple rules apply, choose the first matching from the above list. See
<aclass="reference internal" href="#backport-strategy"><spanclass="std std-ref">Backport strategy</span></a> for detailed guidance on what should or should not be
backported.</p>
<p>The milestone marks the release a PR should go into. It states intent, but can
be changed because of release planning or re-evaluation of the PR scope and
maturity.</p>
<p>All Pull Requests should target the main branch. The milestone tag triggers
an <aclass="reference internal" href="#automated-backports"><spanclass="std std-ref">automatic backport</span></a> for milestones which have
a corresponding branch.</p>
</section>
<sectionid="merging">
<spanid="pr-merging"></span><h3>Merging<aclass="headerlink" href="#merging" title="Link to this heading">#</a></h3>
<ul>
<li><p>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><p>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
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 <aclass="reference external" href="https://docs.github.com/en/github/collaborating-with-pull-requests/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 a file in one of the
subdirectories of <codeclass="file docutils literal notranslate"><spanclass="pre">doc/api/next_api_changes</span></code>, and significant new
features have an entry in <codeclass="file docutils literal notranslate"><spanclass="pre">doc/user/whats_new</span></code>.</p>
<ul>
<li><p>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.</p>
<p>A core dev should only champion one PR at a time and we should try to keep
the flow of championed PRs reasonable.</p>
</li>
</ul>
</li>
<li><p>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>
</ul>
</section>
<sectionid="automated-tests">
<spanid="pr-automated-tests"></span><h3>Automated tests<aclass="headerlink" href="#automated-tests" title="Link to this heading">#</a></h3>
<p>Whenever a pull request is created or updated, various automated test tools
will run on all supported platforms and versions of Python.</p>
<ulclass="simple">
<li><p>Make sure the Linting, GitHub Actions, AppVeyor, CircleCI, and Azure
pipelines are passing before merging (All checks are listed at the bottom of
the GitHub page of your pull request). Here are some tips for finding the
cause of the test failure:</p>
<ul>
<li><p>If <em>Linting</em> fails, you have a code style issue, which will be listed
as annotations on the pull request's diff.</p></li>
<li><p>If <em>Mypy</em> or <em>Stubtest</em> fails, you have inconsistency in type hints, which
will be listed as annotations in the diff.</p></li>
<li><p>If a GitHub Actions or AppVeyor run fails, search the log for <codeclass="docutils literal notranslate"><spanclass="pre">FAILURES</span></code>.
The subsequent section will contain information on the failed tests.</p></li>
<li><p>If CircleCI fails, likely you have some reStructuredText style issue in
the docs. Search the CircleCI log for <codeclass="docutils literal notranslate"><spanclass="pre">WARNING</span></code>.</p></li>
<li><p>If Azure pipelines fail with an image comparison error, you can find the
images as <em>artifacts</em> of the Azure job:</p>
<ul>
<li><p>Click <em>Details</em> on the check on the GitHub PR page.</p></li>
<li><p>Click <em>View more details on Azure Pipelines</em> to go to Azure.</p></li>
<li><p>On the overview page <em>artifacts</em> are listed in the section <em>Related</em>.</p></li>
</ul>
</li>
</ul>
</li>
<li><p>Codecov and CodeQL are currently for information only. Their failure is not
necessarily a blocker.</p></li>
<li><p><aclass="reference external" href="https://tox.readthedocs.io/">tox</a> is not used in the automated testing. It is supported for testing
locally.</p>
</li>
<li><p>If you know only a subset of CIs need to be run, this can be controlled on
individual commits by including the following substrings in commit messages:</p>
<ul>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">[ci</span><spanclass="pre">doc]</span></code>: restrict the CI to documentation checks. For when you only
changed documentation (this skip is automatic if the changes are only under
<codeclass="docutils literal notranslate"><spanclass="pre">doc/</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">galleries/</span></code>).</p></li>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">[skip</span><spanclass="pre">circle]</span></code>: skip the documentation build check. For when you didn't
change documentation.</p></li>
<li><p>Unit tests can be turned off for individual platforms with</p>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">[skip</span><spanclass="pre">appveyor]</span></code> (must be in the first line of the commit): AppVeyor</p></li>
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">[skip</span><spanclass="pre">ci]</span></code>: skip all CIs. Use this only if you know your changes do not
need to be tested at all, which is very rare.</p></li>
</ul>
</li>
</ul>
</section>
<sectionid="number-of-commits-and-squashing">
<spanid="pr-squashing"></span><h3>Number of commits and squashing<aclass="headerlink" href="#number-of-commits-and-squashing" title="Link to this heading">#</a></h3>
<ulclass="simple">
<li><p>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><p>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><p>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>
</section>
</section>
<sectionid="branches-and-backports">
<spanid="id4"></span><h2>Branches and backports<aclass="headerlink" href="#branches-and-backports" title="Link to this heading">#</a></h2>
<sectionid="current-branches">
<h3>Current branches<aclass="headerlink" href="#current-branches" title="Link to this heading">#</a></h3>
<p>The current active branches are</p>
<dlclass="simple">
<dt><em>main</em></dt><dd><p>The current development version. Future minor releases (<em>v3.N.0</em>) will be
branched from this.</p>
</dd>
<dt><em>v3.N.x</em></dt><dd><p>Maintenance branch for Matplotlib 3.N. Future patch releases will be
branched from this.</p>
</dd>
<dt><em>v3.N.M-doc</em></dt><dd><p>Documentation for the current release. On a patch release, this will be
replaced by a properly named branch for the new release.</p>
</dd>
</dl>
</section>
<sectionid="branch-selection-for-pull-requests">
<spanid="pr-branch-selection"></span><h3>Branch selection for pull requests<aclass="headerlink" href="#branch-selection-for-pull-requests" title="Link to this heading">#</a></h3>
<p>Generally, all pull requests should target the main branch.</p>
<p>Other branches are fed through <aclass="reference internal" href="#automated-backports"><spanclass="std std-ref">automatic</span></a> or
targeting other branches is only rarely necessary for special maintenance
work.</p>
</section>
<sectionid="backport-strategy">
<spanid="id5"></span><h3>Backport strategy<aclass="headerlink" href="#backport-strategy" title="Link to this heading">#</a></h3>
<p>Backports to the patch release branch (<em>v3.N.x</em>) are the changes that will be
included in the next patch (aka bug-fix) release. The goal of the patch
releases is to fix bugs without adding any new regressions or behavior changes.
We will always attempt to backport:</p>
<ulclass="simple">
<li><p>critical bug fixes (segfault, failure to import, things that the
user cannot work around)</p></li>
<li><p>fixes for regressions introduced in the last two minor releases</p></li>
</ul>
<p>and may attempt to backport fixes for regressions introduced in older releases.</p>
<p>In the case where the backport is not clean, for example if the bug fix is
built on top of other code changes we do not want to backport, balance the
effort and risk of re-implementing the bug fix vs the severity of the bug.
When in doubt, err on the side of not backporting.</p>
<p>When backporting a Pull Request fails or is declined, re-milestone the original
PR to the next minor release and leave a comment explaining why.</p>
<p>The only changes backported to the documentation branch (<em>v3.N.M-doc</em>)
are changes to <codeclass="file docutils literal notranslate"><spanclass="pre">doc</span></code> or <codeclass="file docutils literal notranslate"><spanclass="pre">galleries</span></code>. Any changes to <codeclass="file docutils literal notranslate"><spanclass="pre">lib</span></code>
or <codeclass="file docutils literal notranslate"><spanclass="pre">src</span></code>, including docstring-only changes, must not be backported to
this branch.</p>
</section>
<sectionid="automated-backports">
<spanid="id6"></span><h3>Automated backports<aclass="headerlink" href="#automated-backports" title="Link to this heading">#</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
MeeseeksDev 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
<spanid="id7"></span><h3>Manual backports<aclass="headerlink" href="#manual-backports" title="Link to this heading">#</a></h3>
<p>When doing backports please copy the form used by MeeseeksDev,
<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 main to v2.2.x assuming:</p>
<ulclass="simple">
<li><p><codeclass="docutils literal notranslate"><spanclass="pre">matplotlib</span></code> is a read-only remote branch of the matplotlib/matplotlib repo</p></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>
git<spanclass="w"></span>checkout<spanclass="w"></span>v2.2.x<spanclass="w"></span><spanclass="c1"># or include -b if you don't already have this.</span>
<p>Use your discretion to push directly to upstream or to open a PR; be
sure to push or PR against the <codeclass="docutils literal notranslate"><spanclass="pre">v2.2.x</span></code> upstream branch, not <codeclass="docutils literal notranslate"><spanclass="pre">main</span></code>!</p>