Pull Request Checklist

All pull request will be reviewed by a core developer who will manage the process of merging. It is the responsibility of a developer submitting a pull request to do their best to deliver a pull request which meets the requirements of the project it is submitted to.

The check list summarises criteria which will be checked before a pull request is merged. Before submitting a pull request please consider this list.

  1. Provide a helpful description of the Pull Request. This should include:

  • The aim of the change / the problem addressed / a link to the issue.

  • How the change has been delivered.

  1. Include a “What’s New” entry, if appropriate. See Contributing a “What’s New” Entry.

  2. Check all tests pass. This includes existing tests and any new tests added for any new functionality. For more information see Running the Tests.

  3. Check all modified and new source files conform to the required Code Formatting.

  4. Check all new dependencies added to the ``requirements/ci/*.yml`` files. If dependencies have been added then new nox testing lockfiles should be generated too, see Cirrus CI Test environment.

  5. Check the source documentation been updated to explain all new or changed features. See Docstrings.

  6. Include code examples inside the docstrings where appropriate. See Testing.

  7. Check the documentation builds without warnings or errors. See Building

  8. Check for any new dependencies in the .cirrus.yml config file.

  9. Check for any new dependencies in the readthedocs.yml file. This file is used to build the documentation that is served from https://scitools-iris.readthedocs.io/en/latest/

  10. Check for updates needed for supporting projects for test or example data. For example:

    If new files are required by tests or code examples, they must be added to the appropriate supporting project via a suitable pull-request. This pull request should be referenced in the main Iris pull request and must be accepted and merged before the Iris one can be.