Content#

• Is the feature / bugfix reasonable?

• Does the PR conform with theCoding guidelines?

• Is thedocumentation (docstrings, examples,what's new, API changes) updated?

• Is the change purely stylistic? Generally, such changes are discouraged whennot part of other non-stylistic work because it obscures the git history offunctional changes to the code. Reflowing a method or docstring as part of alarger refactor/rewrite is acceptable.

Workflow#

• Make sure allautomated tests pass.

• The PR shouldtarget the main branch.

• Tag with descriptivelabels.

• Set themilestone.

• Keep an eye on thenumber of commits.

• Approve if all of the above topics are handled.

• Merge if a sufficient number of approvals is reached.

Documentation#

• Every new feature should be documented. If it's a new module, don'tforget to add a new rst file to the API docs.

• Each high-level plotting function should have a small example intheExamples section of the docstring. This should be as simple aspossible to demonstrate the method. More complex examples should go intoa dedicated example file in theexamples directory, which will berendered to the examples gallery in the documentation.

• Build the docs and make sure all formatting warnings are addressed.

• SeeWrite documentation for our documentation style guide.

Labels#

• If you have the rights to set labels, tag the PR with descriptive labels.See thelist of labels.

• If the PR makes changes to the wheel building Action, add the"Run cibuildwheel" label to enable testing wheels.

Milestones#

Set the milestone according to these guidelines:

• New features and API changes are milestoned for the next meso releasev3.N.0.

• Bugfixes, tests for released code, and docstring changes may be milestonedfor the next micro releasev3.N.M.

• Documentation changes (only .rst files and examples) may be milestonedv3.N-doc.

If multiple rules apply, choose the first matching from the above list. SeeBackport strategy for detailed guidance on what should or should not bebackported.

The milestone marks the release a PR should go into. It states intent, but canbe changed because of release planning or re-evaluation of the PR scope andmaturity.

All Pull Requests should target the main branch. The milestone tag triggersanautomatic backport for milestones which havea corresponding branch.

Merging#

As a guiding principle, we require twoapprovals from core developers (thosewith commit rights) before merging a pull request. This two-pairs-of-eyesstrategy shall ensure a consistent project direction and prevent accidentalmistakes. It is permissible to merge with one approval if the change is notfundamental and can easily be reverted at any time in the future.

Some explicit rules following from this:

• Documentation and examples may be merged with a single approval. Usethe threshold "is this better than it was?" as the review criteria.

• Minorinfrastructure updates, e.g. temporary pinning of broken dependenciesor small changes to the CI configuration, may be merged with a singleapproval.

• Code changes (anything insrc orlib) must have two approvals.

  Ensure that all API changes are documented in a file in one of thesubdirectories ofdoc/api/next_api_changes, and significant newfeatures have an entry indoc/user/whats_new.

  • If a PR already has a positive review, a core developer (e.g. the firstreviewer, but not necessarily) may champion that PR for merging. In orderto do so, they should ping all core devs both on GitHub and on the devmailing 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, orsimply request that it gets a second review before being merged. If no oneasks for such a second review within a week, the PR can then be merged onthe basis of that single review.

    A core dev should only champion one PR at a time and we should try to keepthe flow of championed PRs reasonable.

After giving the last required approval, the author of the approval shouldmerge the PR. PR authors should not self-merge except for when another reviewerexplicitly allows it (e.g., "Approve modulo CI passing, may self merge whengreen", or "Take or leave the comments. You may self merge".).

Automated tests#

Before being merged, a PR should pass theAutomated tests. If you areunsure why a test is failing, ask on the PR or in ourOfficial communication channels

Number of commits and squashing#

• Squashing is case-by-case. The balance is between burden on thecontributor, keeping a relatively clean history, and keeping ahistory usable for bisecting. The only time we are really strictabout it is to eliminate binary files (ex multiple test imagere-generations) and to remove upstream merges.

• Do not let perfect be the enemy of the good, particularly fordocumentation or example PRs. If you find yourself making manysmall suggestions, either open a PR against the original branch,push changes to the contributor branch, or merge the PR and thenopen a new PR against upstream.

• If you push to a contributor branch leave a comment explaining whatyou did, ex "I took the liberty of pushing a small clean-up PR toyour branch, thanks for your work.". If you are going to makesubstantial changes to the code or intent of the PR please checkwith the contributor first.

Current branches#

The current active branches are

main

The current development version. Future meso (v3.N.0) or macro (v4.0.0) will bebranched from this.

v3.N.x

Maintenance branch for Matplotlib 3.N. Future micro releases will betagged from this.

v3.N.M-doc

Documentation for the current micro release. On a micro release, this will bereplaced by a properly named branch for the new release.

Branch selection for pull requests#

Generally, all pull requests should target the main branch.

Other branches are fed throughautomatic ormanual. Directlytargeting other branches is only rarely necessary for special maintenancework.

Backport strategy#

Backports to the micro release branch (v3.N.x) are the changes that will beincluded in the next patch (aka bug-fix) release. The goal of the patchreleases is to fix bugs without adding any new regressions or behavior changes.We will always attempt to backport:

• critical bug fixes (segfault, failure to import, things that theuser cannot work around)

• fixes for regressions introduced in the last two meso releases

and may attempt to backport fixes for regressions introduced in older releases.

In the case where the backport is not clean, for example if the bug fix isbuilt on top of other code changes we do not want to backport, balance theeffort and risk of re-implementing the bug fix vs the severity of the bug.When in doubt, err on the side of not backporting.

When backporting a Pull Request fails or is declined, re-milestone the originalPR to the next meso release and leave a comment explaining why.

The only changes backported to the documentation branch (v3.N.M-doc)are changes todoc orgalleries. Any changes toliborsrc, including docstring-only changes, must not be backported tothis branch.

Automated backports#

We use MeeseeksDev bot to automatically backport merges to the correctmaintenance branch base on the milestone. To work properly themilestone must be set before merging. If you have commit rights, thebot can also be manually triggered after a merge by leaving a message@meeseeksdevbackporttoBRANCH on the PR. If there are conflictsMeeseeksDev will inform you that the backport needs to be donemanually.

The target branch is configured by puttingon-merge:backporttoTARGETBRANCH in the milestone description on it's own line.

If the bot is not working as expected, please report issues toMeeseeksDev.

Manual backports#

When doing backports please copy the form used by MeeseeksDev,BackportPR#XXXX:TITLEOFPR. If you need to manually resolveconflicts make note of them and how you resolved them in the commitmessage.

We do a backport from main to v2.2.x assuming:

• matplotlib is a read-only remote branch of the matplotlib/matplotlib repo

TheTARGET_SHA is the hash of the merge commit you would like tobackport. This can be read off of the GitHub PR page (in the UI withthe merge notification) or through the git CLI tools.

Assuming that you already have a local branchv2.2.x (if not, thengitcheckout-bv2.2.x), and that your remote pointing tohttps://github.com/matplotlib/matplotlib is calledupstream:

gitfetchupstreamgitcheckoutv2.2.x# or include -b if you don't already have this.gitreset--hardupstream/v2.2.xgitcherry-pick-m1TARGET_SHA# resolve conflicts and commit if required

Files with conflicts can be listed bygitstatus,and will have to be fixed by hand (search on>>>>>). Oncethe conflict is resolved, you will have to re-add the file(s) to the branchand then continue the cherry pick:

gitaddlib/matplotlib/conflicted_file.pygitaddlib/matplotlib/conflicted_file2.pygitcherry-pick--continue

Use your discretion to push directly to upstream or to open a PR; besure to push or PR against thev2.2.x upstream branch, notmain!