From 15312e7adf704d70fea30c7e9cff00ec9ed8e94c Mon Sep 17 00:00:00 2001 From: Martin Yeo Date: Thu, 21 May 2026 17:37:46 +0100 Subject: [PATCH 1/6] Use a simpler pull request checklist, part of the GitHub template. --- .github/pull_request_template.md | 25 +++++---- .../contributing_ci_tests.rst | 14 +++++ .../contributing_pull_request_checklist.rst | 54 ++----------------- 3 files changed, 34 insertions(+), 59 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 34bc59182c..251f9b8ca6 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,14 +1,21 @@ -## 🚀 Pull Request +## Description -### Description - - +_Please describe your awesome pull request_ +## Checklist ---- -[Consult Iris pull request check list]( https://scitools-iris.readthedocs.io/en/latest/developers_guide/contributing_pull_request_checklist.html) +(In addition to a full set of [passing checks](https://scitools-iris.readthedocs.io/en/latest/developers_guide/contributing_ci_tests.html) :white_check_mark:) ---- -Add any of the below labels to trigger actions on this PR: +- [ ] Included a [**What's New**](https://scitools-iris.readthedocs.io/en/latest/developers_guide/documenting/whats_new_contributions.html) entry +- [ ] Checked if [**tests**](https://scitools-iris.readthedocs.io/en/latest/developers_guide/contributing_tests.html) need updating +- [ ] Checked if [**benchmarks**](../benchmarks/README.md#writing-benchmarks) need updating +- [ ] Checked if **documentation** needs updating + - [Docstrings](https://scitools-iris.readthedocs.io/en/latest/developers_guide/documenting/docstrings.html) (we love code examples!) + - [User Manual](https://scitools-iris.readthedocs.io/en/latest/user_manual/) pages +- [ ] Checked if [**dependencies**](https://scitools-iris.readthedocs.io/en/latest/developers_guide/contributing_ci_tests.html#gha-test-env) need updating -- https://github.com/SciTools/iris/labels/benchmark_this +--- +> [!TIP] +> Add any of the below labels to trigger actions on this PR: +> +> - https://github.com/SciTools/iris/labels/benchmark_this diff --git a/docs/src/developers_guide/contributing_ci_tests.rst b/docs/src/developers_guide/contributing_ci_tests.rst index 542178c2ff..9be1c8f749 100644 --- a/docs/src/developers_guide/contributing_ci_tests.rst +++ b/docs/src/developers_guide/contributing_ci_tests.rst @@ -90,6 +90,20 @@ If any CI tasks fail, then the pull-request is unlikely to be merged to the Iris target branch by a core developer. +Data Repositories +----------------- + +Two other SciTools repositories support the CI tasks: + +* `iris-test-data`_ is a github project containing all the data to support the tests. +* `iris-sample-data`_ is a github project containing all the data to support the gallery and examples. + +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. + + .. _testing_cla: `CLA Assistant`_ diff --git a/docs/src/developers_guide/contributing_pull_request_checklist.rst b/docs/src/developers_guide/contributing_pull_request_checklist.rst index 11d68ace46..8fb56467b2 100644 --- a/docs/src/developers_guide/contributing_pull_request_checklist.rst +++ b/docs/src/developers_guide/contributing_pull_request_checklist.rst @@ -5,57 +5,11 @@ 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 the contributor submitting a -pull request to do their best to deliver a pull request which meets the -requirements of the project it is submitted to. +.. attention:: -This check list summarises criteria which will be checked before a pull request -is merged. Before submitting a pull request please consider the following: + The checklist has moved! + The latest checklist is now part of the `GitHub pull request template`_. -#. **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. - -#. **Include a "What's New" entry**, if appropriate. - See :ref:`whats_new_contributions`. - -#. **Check all tests pass**. This includes existing tests and any new tests - added for any new functionality. For more information see - :ref:`developer_running_tests`. - -#. **Check all modified and new source files conform to the required** - :ref:`code_formatting`. - -#. **Check all new dependencies added to the** `requirements`_ **yaml - files.** If dependencies have been added then new nox testing lockfiles - should be generated too, see :ref:`gha_test_env`. - -#. **Check the source documentation been updated to explain all new or changed - features**. Note, we now use numpydoc strings. Any touched code should - be updated to use the docstrings formatting. See :ref:`docstrings`. - -#. **Include code examples inside the docstrings where appropriate**. See - :ref:`contributing.documentation.testing`. - -#. **Check the documentation builds without warnings or errors**. See - :ref:`contributing.documentation.building` - -#. **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/ - -#. **Check for updates needed for supporting projects for test or example - data**. For example: - - * `iris-test-data`_ is a github project containing all the data to support - the tests. - * `iris-sample-data`_ is a github project containing all the data to support - the gallery and examples. - - 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. +.. _GitHub pull request template: https://github.com/SciTools/iris/blob/main/.github/pull_request_template.md \ No newline at end of file From 5742f6129a5bbdec5947eb8bc1260b5ba0b2acbf Mon Sep 17 00:00:00 2001 From: Martin Yeo Date: Fri, 22 May 2026 14:22:19 +0100 Subject: [PATCH 2/6] Updates to Code Formatting page. --- .github/pull_request_template.md | 1 + .../contributing_code_formatting.rst | 31 ++++++++++--------- 2 files changed, 17 insertions(+), 15 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 251f9b8ca6..bb884fa630 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -7,6 +7,7 @@ _Please describe your awesome pull request_ (In addition to a full set of [passing checks](https://scitools-iris.readthedocs.io/en/latest/developers_guide/contributing_ci_tests.html) :white_check_mark:) - [ ] Included a [**What's New**](https://scitools-iris.readthedocs.io/en/latest/developers_guide/documenting/whats_new_contributions.html) entry +- [ ] Incorporated [**type hints**](https://scitools-iris.readthedocs.io/en/latest/developers_guide/contributing_code_formatting.html#type-hinting) in any changed code - [ ] Checked if [**tests**](https://scitools-iris.readthedocs.io/en/latest/developers_guide/contributing_tests.html) need updating - [ ] Checked if [**benchmarks**](../benchmarks/README.md#writing-benchmarks) need updating - [ ] Checked if **documentation** needs updating diff --git a/docs/src/developers_guide/contributing_code_formatting.rst b/docs/src/developers_guide/contributing_code_formatting.rst index bb3140e4f9..b2d4639138 100644 --- a/docs/src/developers_guide/contributing_code_formatting.rst +++ b/docs/src/developers_guide/contributing_code_formatting.rst @@ -5,14 +5,15 @@ Code Formatting =============== -To ensure a consistent code format throughout Iris, we recommend using -tools to check the source directly. +Also known as 'linting'. This is used to ensure a consistent code format +throughout Iris, maximising the maintainability and quality. Code formatting +is checked using the `pre-commit`_ tool, and the full list current formatting +tools is defined in Iris' `pre-commit-config.yaml`_ file. Read more about +linting on the `SciTools wiki page`_. -* `black`_ for an opinionated coding auto-formatter -* `flake8`_ linting checks - -The preferred way to run these tools automatically is to setup and configure -`pre-commit`_. +``pre-commit`` compliance is automatically checked on all Iris pull requests +(more info: :ref:`pre_commit_ci`), but you can also run pre-commit locally as +Git hooks - every time you make a commit: You can install ``pre-commit`` in your development environment using ``pip``:: @@ -32,15 +33,14 @@ the root directory of Iris:: $ pre-commit install -Upon performing a ``git commit``, your code will now be automatically formatted -to the ``black`` configuration defined in our ``pyproject.toml`` file, and -linted according to our ``.flake8`` configuration file. Note that, +Upon performing a ``git commit``, your code changes will be automatically +checked against all Iris' ``pre-commit`` hooks. For some hooks this includes +automated edits of your code e.g. formatting or sorting of imports; these new +edits are not staged for you - i.e. you need to run ``git add`` again on that +file. Note that, ``pre-commit`` will automatically download and install the necessary packages for each ``.pre-commit-config.yaml`` git hook. -Additionally, you may wish to enable ``black`` for your preferred -`editor/IDE `_. - With the ``pre-commit`` configured, the output of performing a ``git commit`` will look similar to:: @@ -54,8 +54,7 @@ will look similar to:: 2 files changed, 10 insertions(+), 9 deletions(-) -.. note:: You can also run `black`_ and `flake8`_ manually. Please see the - their officially documentation for more information. +.. _type_hinting: Type Hinting ------------ @@ -67,3 +66,5 @@ add/improve them. .. _pre-commit: https://pre-commit.com/ +.. _pre-commit-config.yaml: https://github.com/SciTools/iris/blob/main/.pre-commit-config.yaml +.. _SciTools wiki page: https://github.com/SciTools/.github/wiki/Linting From 29e520c7cbb7880651ebab4322ccd3c114c40f28 Mon Sep 17 00:00:00 2001 From: Martin Yeo Date: Fri, 22 May 2026 14:57:21 +0100 Subject: [PATCH 3/6] Improved formatting of benchmarks docs. --- benchmarks/README.md | 82 +++++++++-------------- benchmarks/custom_bms/README.md | 2 +- benchmarks/custom_bms/install.py | 2 +- benchmarks/custom_bms/tracemallocbench.py | 2 +- 4 files changed, 35 insertions(+), 53 deletions(-) diff --git a/benchmarks/README.md b/benchmarks/README.md index 372441a0b9..d346c85038 100644 --- a/benchmarks/README.md +++ b/benchmarks/README.md @@ -13,13 +13,17 @@ shifts in performance being flagged in a new GitHub issue. On GitHub: a Pull Request can be benchmarked by adding the https://github.com/SciTools/iris/labels/benchmark_this -label to the PR (to run a second time: just remove and re-add the label). +label to the PR. Note that a benchmark run could take an hour or more to complete. This runs a comparison between the PR branch's ``HEAD`` and its merge-base with the PR's base branch, thus showing performance differences introduced by the PR. (This run is managed by [the aforementioned GitHub Action](../.github/workflows/benchmark.yml)). +> [!TIP] +> To run the benchmarks a second time: remove the +> https://github.com/SciTools/iris/labels/benchmark_this label and add it again. + To run locally: the **benchmark runner** provides conveniences for common benchmark setup and run tasks, including replicating the benchmarking performed by GitHub Actions workflows. This can be accessed by: @@ -48,42 +52,17 @@ are not already. This can be done in several ways: ### Environment variables -* `OVERRIDE_TEST_DATA_REPOSITORY` - required - some benchmarks use -`iris-test-data` content, and your local `site.cfg` is not available for -benchmark scripts. The benchmark runner defers to any value already set in -the shell, but will otherwise download `iris-test-data` and set the variable -accordingly. -* `DATA_GEN_PYTHON` - required - path to a Python executable that can be -used to generate benchmark test objects/files; see -[Data generation](#data-generation). The benchmark runner sets this -automatically, but will defer to any value already set in the shell. Note that -[Mule](https://github.com/MetOffice/mule) will be automatically installed into -this environment, and sometimes -[iris-test-data](https://github.com/SciTools/iris-test-data) (see -`OVERRIDE_TEST_DATA_REPOSITORY`). -* `BENCHMARK_DATA` - optional - path to a directory for benchmark synthetic -test data, which the benchmark scripts will create if it doesn't already -exist. Defaults to `/benchmarks/.data/` if not set. Note that some of -the generated files, especially in the 'SPerf' suite, are many GB in size so -plan accordingly. -* `ON_DEMAND_BENCHMARKS` - optional - when set (to any value): benchmarks -decorated with `@on_demand_benchmark` are included in the ASV run. Usually -coupled with the ASV `--bench` argument to only run the benchmark(s) of -interest. Is set during the benchmark runner `cperf` and `sperf` sub-commands. -* `ASV_COMMIT_ENVS` - optional - instruct the -[delegated environment management](#benchmark-environments) to create a -dedicated environment for each commit being benchmarked when set (to any -value). This means that benchmarking commits with different environment -requirements will not be delayed by repeated environment setup - especially -relevant given the [benchmark runner](bm_runner.py)'s use of -[--interleave-rounds](https://asv.readthedocs.io/en/stable/commands.html?highlight=interleave-rounds#asv-run), -or any time you know you will repeatedly benchmark the same commit. **NOTE:** -SciTools environments tend to large so this option can consume a lot of disk -space. +| Name | Required | Description | Notes | +|------|----------|-------------|-------| +| `OVERRIDE_TEST_DATA_REPOSITORY` | **required** | Some benchmarks use `iris-test-data` content, and your local `site.cfg` is not available for benchmark scripts. The benchmark runner defers to any value already set in the shell, but will otherwise download `iris-test-data` and set the variable accordingly. | | +| `DATA_GEN_PYTHON` | **required** | Path to a Python executable that can be used to generate benchmark test objects/files; see [Data generation](#data-generation). The benchmark runner sets this automatically, but will defer to any value already set in the shell. | [Mule](https://github.com/MetOffice/mule) will be automatically installed into this environment, and sometimes [iris-test-data](https://github.com/SciTools/iris-test-data) (see `OVERRIDE_TEST_DATA_REPOSITORY`). | +| `BENCHMARK_DATA` | optional | Path to a directory for benchmark synthetic test data, which the benchmark scripts will create if it doesn't already exist. Defaults to `/benchmarks/.data/` if not set. | Some of the generated files, especially in the 'SPerf' suite, are many GB in size so plan accordingly. | +| `ON_DEMAND_BENCHMARKS` | optional | When set (to any value): benchmarks decorated with `@on_demand_benchmark` are included in the ASV run. Usually coupled with the ASV `--bench` argument to only run the benchmark(s) of interest. Is set during the benchmark runner `cperf` and `sperf` sub-commands. | | +| `ASV_COMMIT_ENVS` | optional | Instruct the [delegated environment management](#benchmark-environments) to create a dedicated environment for each commit being benchmarked when set (to any value). This means that benchmarking commits with different environment requirements will not be delayed by repeated environment setup - especially relevant given the [benchmark runner](bm_runner.py)'s use of [--interleave-rounds](https://asv.readthedocs.io/en/stable/commands.html?highlight=interleave-rounds#asv-run), or any time you know you will repeatedly benchmark the same commit. | **SciTools environments tend to be large so this option can consume a lot of disk space.** | ## Writing benchmarks -[See the ASV docs](https://asv.readthedocs.io/) for full detail. +[See the ASV docs](https://asv.readthedocs.io/en/stable/) for full detail. ### What benchmarks to write @@ -96,19 +75,21 @@ positive regressions. We therefore recommend writing benchmarks representing scripts or single operations that are likely to be run at the user level. -The drawback of this approach: a reported regression is less likely to reveal -the root cause (e.g. if a commit caused a regression in coordinate-creation -time, but the only benchmark covering this was for file-loading). Be prepared -for manual investigations; and consider committing any useful benchmarks as -[on-demand benchmarks](#on-demand-benchmarks) for future developers to use. +> [!CAUTION] +> The drawback of this approach: a reported regression is less likely to reveal +> the root cause (e.g. if a commit caused a regression in coordinate-creation +> time, but the only benchmark covering this was for file-loading). Be prepared +> for manual investigations; and consider committing any useful benchmarks as +> [on-demand benchmarks](#on-demand-benchmarks) for future developers to use. ### Data generation -**Important:** be sure not to use the benchmarking environment to generate any -test objects/files, as this environment changes with each commit being -benchmarked, creating inconsistent benchmark 'conditions'. The -[generate_data](./benchmarks/generate_data/__init__.py) module offers a -solution; read more detail there. +> [!WARNING] +> Be sure not to use the benchmarking environment to generate any +> test objects/files, as this environment changes with each commit being +> benchmarked, creating inconsistent benchmark 'conditions'. The +> [generate_data](./benchmarks/generate_data/__init__.py) module offers a +> solution; read more detail there. ### ASV re-run behaviour @@ -136,9 +117,10 @@ detail. ### Scaling / non-Scaling Performance Differences -**(We no longer advocate the below for benchmarks run during CI, given the -limited available runtime and risk of false-positives. It remains useful for -manual investigations).** +> [!CAUTION] +> We no longer advocate the below for benchmarks run during CI, given the +> limited available runtime and risk of false-positives. It remains useful for +> manual investigations. When comparing performance between commits/file-type/whatever it can be helpful to know if the differences exist in scaling or non-scaling parts of the @@ -160,7 +142,7 @@ suites for the UK Met Office NG-VAT project. ## Benchmark environments -We have disabled ASV's standard environment management, instead using an +We have disabled ASV's standard environment management[^1], instead using an environment built using the same scripts that set up the package test environments. This is done using ASV's plugin architecture - see @@ -168,8 +150,8 @@ This is done using ASV's plugin architecture - see references in [`asv.conf.json`](asv.conf.json) (`environment_type` and `plugins`). -(ASV is written to control the environment(s) that benchmarks are run in - +[^1]: ASV is written to control the environment(s) that benchmarks are run in - minimising external factors and also allowing it to compare between a matrix of dependencies (each in a separate environment). We have chosen to sacrifice these features in favour of testing each commit with its intended dependencies, -controlled by the test environment setup script(s)). +controlled by the test environment setup script(s). diff --git a/benchmarks/custom_bms/README.md b/benchmarks/custom_bms/README.md index eea85d74fe..ab763623d5 100644 --- a/benchmarks/custom_bms/README.md +++ b/benchmarks/custom_bms/README.md @@ -2,7 +2,7 @@ To be recognised by ASV, these benchmarks must be packaged and installed in line with the -[ASV guidelines](https://asv.readthedocs.io/projects/asv-runner/en/latest/development/benchmark_plugins.html). +[ASV guidelines](https://asv.readthedocs.io/projects/asv-runner/en/stable/development/benchmark_plugins.html). This is achieved using the custom build in [install.py](./install.py). Installation is into the environment where the benchmarks are run (i.e. not diff --git a/benchmarks/custom_bms/install.py b/benchmarks/custom_bms/install.py index bda9f1cc3c..7cdd98f392 100644 --- a/benchmarks/custom_bms/install.py +++ b/benchmarks/custom_bms/install.py @@ -5,7 +5,7 @@ """Install the SciTools custom benchmarks for detection by ASV. See the requirements for being detected as an ASV plugin: -https://asv.readthedocs.io/projects/asv-runner/en/latest/development/benchmark_plugins.html +https://asv.readthedocs.io/projects/asv-runner/en/stable/development/benchmark_plugins.html """ from pathlib import Path diff --git a/benchmarks/custom_bms/tracemallocbench.py b/benchmarks/custom_bms/tracemallocbench.py index 486c67aeb9..77946e1e17 100644 --- a/benchmarks/custom_bms/tracemallocbench.py +++ b/benchmarks/custom_bms/tracemallocbench.py @@ -192,5 +192,5 @@ def too_slow(num_samples) -> bool: return samples, 1 -# https://asv.readthedocs.io/projects/asv-runner/en/latest/development/benchmark_plugins.html +# https://asv.readthedocs.io/projects/asv-runner/en/stable/development/benchmark_plugins.html export_as_benchmark = [TracemallocBenchmark] From bae23cf2018dd3896e5a0de29add234106357477 Mon Sep 17 00:00:00 2001 From: Martin Yeo Date: Fri, 22 May 2026 16:33:23 +0100 Subject: [PATCH 4/6] Updates to Contributing a Whats New page. --- .../documenting/whats_new_contributions.rst | 83 +++++++++++-------- 1 file changed, 49 insertions(+), 34 deletions(-) diff --git a/docs/src/developers_guide/documenting/whats_new_contributions.rst b/docs/src/developers_guide/documenting/whats_new_contributions.rst index 10fa72cb8d..4e2f431079 100644 --- a/docs/src/developers_guide/documenting/whats_new_contributions.rst +++ b/docs/src/developers_guide/documenting/whats_new_contributions.rst @@ -6,52 +6,56 @@ Contributing a "What's New" Entry ================================= -Iris uses a file named ``latest.rst`` to keep a draft of upcoming development -changes that will form the next stable release. Contributions to the -:ref:`iris_whatsnew` document are written by the developer most familiar -with the change made. The contribution should be included as part of -the Iris Pull Request that introduces the change. - -The ``latest.rst`` and the past release notes are kept in the -``docs/src/whatsnew/`` directory. If you are writing the first contribution after -an Iris release: **create the new** ``latest.rst`` by copying the content from -``latest.rst.template`` in the same directory. +Please include a "What's New" contribution in +``docs/src/whatsnew/latest.rst`` for **any** change that you make to Iris. +**Even if it is not relevant to users** - the `Contribution categories`_ +include ``Internal`` for this - the page is read by contributors as well as +users, and it reveals the work needed to keep a project going. -Since the `Contribution categories`_ include Internal changes, **all** Iris -Pull Requests should be accompanied by a "What's New" contribution. +See this docs section for all What's New pages: :ref:`iris_whatsnew`. +What Should it Look Like? +========================= -Git Conflicts -============= +It should describe your change in a few sentences, with particular focus on +what the change means for users who might read this. For formatting guidance: +hundreds of examples can be found in existing ``docs/src/whatsnew/`` files, +or read the `Detail`_ section below for precise instructions. -If changes to ``latest.rst`` are being suggested in several simultaneous -Iris Pull Requests, Git will likely encounter merge conflicts. If this -situation is thought likely (large PR, high repo activity etc.): +.. hint:: -* PR author: Do not include a "What's New" entry. Mention in the PR text that a - "What's New" entry is pending + Our standard format includes the number of the pull request making the + change. If you have not yet created the pull request, you can work out + what the next PR number (i.e. your number) will be using this command:: -* PR reviewer: Review the PR as normal. Once the PR is acceptable, ask that - a **new pull request** be created specifically for the "What's New" entry, - which references the main pull request and titled (e.g. for PR#9999): + $ curl -s "https://api.github.com/repos/SciTools/iris/issues?sort=created&direction=desc&per_page=1" | jq -r '.[0].number' - What's New for #9999 +Git Conflicts +============= -* PR author: create the "What's New" pull request +Because every pull request includes a What's New entry, there are often +conflicts for the ``latest.rst`` file. Thankfully What's New files are simple! +GitHub's '`Resolve conflicts`_' button on the pull request provides an easy +interface for fixing these. Or feel free to use a different approach if you +prefer. -* PR reviewer: once the "What's New" PR is created, **merge the main PR**. - (this will fix any `Iris GitHub Actions`_ linkcheck errors where the links in the - "What's New" PR reference new features introduced in the main PR) +**If you are unsure, say so in a comment on your pull request and the Iris +development team will be happy to help.** -* PR reviewer: review the "What's New" PR, merge once acceptable +Detail +====== -These measures should mean the suggested ``latest.rst`` changes are outstanding -for the minimum time, minimising conflicts and minimising the need to rebase or -merge from trunk. +Iris uses a file named ``latest.rst`` to keep a draft of upcoming development +changes that will form the next stable release. Contributions to the +:ref:`iris_whatsnew` document are written by the developer most familiar +with the change made. The contribution should be included as part of +the Iris Pull Request that introduces the change. +The ``latest.rst`` and the past release notes are kept in the +``docs/src/whatsnew/`` directory. Writing a Contribution -====================== +---------------------- A contribution is the short description of a change introduced to Iris which improved it in some way. As such, a single Iris Pull Request may @@ -124,9 +128,8 @@ examine past what's :ref:`iris_whatsnew` entries. creating a pull request, however you can also manually :ref:`build ` the documentation. - Contribution Categories -======================= +----------------------- The structure of the what's new release note should be easy to read by users. To achieve this several categories may be used. @@ -155,3 +158,15 @@ users. To achieve this several categories may be used. **💼 Internal** Changes to any internal or development related topics, such as testing, environment dependencies etc. + +Making a File +------------- + +This is usually handled as part of the :ref:`iris_development_releases` process. +But if you are making the first contribution to a new minor or major release, +and you find that no ``docs/src/whatsnew/latest.rst`` file exists: +**create the new** ``latest.rst`` by copying the content from +``latest.rst.template`` in the same directory. + + +.. _Resolve conflicts: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github From c9b51e9088c950d5c1394bc1a97109e7362fbdd3 Mon Sep 17 00:00:00 2001 From: Martin Yeo Date: Fri, 22 May 2026 16:34:26 +0100 Subject: [PATCH 5/6] Correct PR number curl command. --- .../developers_guide/documenting/whats_new_contributions.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/developers_guide/documenting/whats_new_contributions.rst b/docs/src/developers_guide/documenting/whats_new_contributions.rst index 4e2f431079..bb622c25cb 100644 --- a/docs/src/developers_guide/documenting/whats_new_contributions.rst +++ b/docs/src/developers_guide/documenting/whats_new_contributions.rst @@ -28,7 +28,7 @@ or read the `Detail`_ section below for precise instructions. change. If you have not yet created the pull request, you can work out what the next PR number (i.e. your number) will be using this command:: - $ curl -s "https://api.github.com/repos/SciTools/iris/issues?sort=created&direction=desc&per_page=1" | jq -r '.[0].number' + $ curl -s "https://api.github.com/repos/SciTools/iris/issues?sort=created&direction=desc&per_page=1" | jq -r '.[0].number + 1' Git Conflicts ============= From 8a74da361de112e81abccedf52ec590e82fd4537 Mon Sep 17 00:00:00 2001 From: Martin Yeo Date: Fri, 22 May 2026 16:36:47 +0100 Subject: [PATCH 6/6] What's New entry. --- docs/src/whatsnew/latest.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/src/whatsnew/latest.rst b/docs/src/whatsnew/latest.rst index 3ed7c8407a..f325556d03 100644 --- a/docs/src/whatsnew/latest.rst +++ b/docs/src/whatsnew/latest.rst @@ -88,6 +88,10 @@ This document explains the changes made to Iris for this release sorted column or row as is uses the incorrect theme color (light). Also updated the datatables version from 2.3.2 to 2.3.8. (:pull:`7079`) +#. `@trexfeathers`_ simplified the pull request checklist and moved it directly + into the GitHub pull request template (read more here: :ref:`pr_check`). Also + updated several associated pages of more detailed guidance. (:pull:`7096`) + 💼 Internal ===========