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'

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: