reviewer suggestions

Author: james-bruten-mo

source/Development/TestSuites/multi-repo_testing.rst

@@ -4,10 +4,10 @@ Multi-Repository Testing
 ========================
 
 Multi-repository changes are expected to pass the regression tests for all the
-repositories involved. To carry out the tests involved in a linked PR it can be
-helpful to refer to the :ref:`repository figure <multirepo>`; testing both child
-and parent repositories as needed. Further details of how testing in each
-repository is handled can be found on the :ref:`Testing page<testing>`.
+repositories involved. To carry out the tests involved in a linked pull request
+it can be helpful to refer to the :ref:`repository figure <multirepo>`; testing
+both child and parent repositories as needed. Further details of how testing in
+each repository is handled can be found on the :ref:`Testing page<testing>`.
 
 All Simulation Systems repositories containing a test suite will also contain a
 ``dependencies.yaml`` file in the top directory of the repository. This file

source/Development/TestSuites/ukca.rst

@@ -2,7 +2,7 @@ Testing UKCA
 ============
 
 Changes in UKCA that touch `src/science` or `src/control/core` must be tested
-with both the UM and LFRic by following the :ref:`linked pull requests 
+with both the UM and LFRic by following the :ref:`linked pull requests
 guidance <multirepo>`.
 
 For further guidance on testing and working with UKCA, including standard

source/Development/inputs.rst

@@ -102,8 +102,8 @@ whether an upgrade macro is necessary.
     cd rose-meta
     rose edit -C ../rose-stem/app/APP-NAME --no-warn version
 
-  If you have a linked LFRic Core or Jules development with metadata changes, 
-  you can load their metadata by adding 
+  If you have a linked LFRic Core or Jules development with metadata changes,
+  you can load their metadata by adding
   ``-M /path/to/working_copy/rose-meta`` to the ``rose-edit`` command.
 
 
@@ -123,7 +123,7 @@ Adding a new metadata section requires:
   (see existing ones for examples)
 
 The ``vnX.Y`` and ``HEAD`` metadata should be identical for this initial
-PR, other than any import statements, which should point at vnX.Y or HEAD
+change, other than any import statements, which should point at vnX.Y or HEAD
 respectively. Other ``vnX.Y`` and ``versionAB_CD.py`` files shouldn't be
 modified or added (these are a snapshot of the metadata at a release).
 

source/Development/kgo.rst

@@ -13,7 +13,7 @@ may also be required to simply add a new job to the test suite or to port the
 rose stem suite to new HPC architecture.
 
 **LFRic** KGO checksums are stored in the repository. As such with LFRic
-pull requests the expectation is that you, as the developer, will include 
+pull requests the expectation is that you, as the developer, will include
 updated KGO files as part of your branch.
 
 **UM and JULES** KGO output files are stored outside of the repository. Access

source/Development/planning_your_change.rst

@@ -64,7 +64,7 @@ aware of these.
 
 **Who will SciTech review the change?** This is a useful consideration as not
 everyone who uses the repository has the knowledge or experience to review
-every PR that is being developed. Get in touch with your SciTech reviewer
+every change that is being developed. Get in touch with your SciTech reviewer
 early in the process as they will have valuable insights that can help to shape
 your change.
 

source/FurtherDetails/dos_donts.rst

@@ -19,7 +19,7 @@ sometimes years later.
 <docs>` and code comments. These help others and your future-self understand
 your work.
 
-**Meaningful names** for issues, pull requests, branches and variables. These 
+**Meaningful names** for issues, pull requests, branches and variables. These
 help others and your future-self understand your work. "My_Branch", "Fix" are
 not helpful.
 

source/FurtherDetails/glossary.rst

@@ -14,9 +14,9 @@ Code Review Deadline:
     moved into code review.
 
 CodeSys Review:
-    A technical review of the changes involved in the PR, including checks
-    that code standards have been upheld and that the working practices have
-    been followed. These reviews are generally completed by a member of the
+    A technical review of the changes involved in the pull request, including
+    checks that code standards have been upheld and that the working practices
+    have been followed. These reviews are generally completed by a member of the
     Simulation IT Team. Once a review has been approved the Code Systems
     Reviewer is then responsible for committing the change to the trunk.
 
@@ -37,13 +37,14 @@ Head of Trunk:
     since the last revision.
 
 Linked Pull Request (Linked PR):
-    Work that spans two or more repositories, requiring pull requests that 
+    Work that spans two or more repositories, requiring pull requests that
     should be treated together and committed as a group.
 
 Overarching Issue:
     Where a piece of work has been split into multiple sections an overarching
     issue can be used to track this work. It should be closed when the whole arc
-    has been completed.
+    has been completed. GitHub also allows subissues which can be created from
+    the overarching issue.
 
 Regression:
     A set of tests that prove that a set of code changes have not degraded the

source/FurtherDetails/who.rst

@@ -79,9 +79,9 @@ of model evolution.
 Sci/Tech Reviewer
 -----------------
 
-A Sci/Tech reviewer is assigned for every pull request and comprises the first 
-stage of review that considers the change as a whole. Further details are found 
-in the :ref:`Scitech Reviewers Guide<scitech_review>`. In some cases, the 
+A Sci/Tech reviewer is assigned for every pull request and comprises the first
+stage of review that considers the change as a whole. Further details are found
+in the :ref:`Scitech Reviewers Guide<scitech_review>`. In some cases, the
 reviewer can delegate parts of the work to another person.
 
 Reviews should be turned around on a reasonable timescale and follow the
@@ -96,8 +96,8 @@ most relevant code owner.
 Code Reviewer
 -------------
 
-The Code Reviewer performs the 2nd stage of review for every pull 
-request. Further details are described in the :ref:`Code Reviewers 
+The Code Reviewer performs the 2nd stage of review for every pull
+request. Further details are described in the :ref:`Code Reviewers
 Guide<code_review>`.
 
 Reviews should be turned around on a reasonable timescale and follow the Code