trac and ticket keyword blat

source/Development/Diagnostics/um_stashmaster.rst

@@ -18,9 +18,6 @@ The UM's ``STASHmaster_A`` and associated help text file
 
 The following principles apply when altering the STASHmaster:
 
-..
-  JW suggest need to include STASH entry guidance here. Maybe an issue for this would be useful?
-
 * If you add a new diagnostic to the ``STASHmaster_A`` file then you **must**
   also add to the stash master help text in :ref:`stashmaster-meta`.
 * If you are altering the stashmaster, this may be referred to the FFPP
@@ -29,7 +26,7 @@ The following principles apply when altering the STASHmaster:
 * If your change has new stash items or changed/added attributes as an option
   code, versions mask etc., then first you have to get them reserved and
   recorded (published) on the reservation web page STASH/ReservedCodes
-* Note that every reservation should be linked to a ticket with the correct
+* Note that every reservation should be linked to an Issue with the correct
   explanation and a milestone. This rule applies to all stash related tables
   placed on this page.
 * Although reservations could be some kind of self-service, contact the section

source/Development/TestSuites/jules.rst

@@ -44,7 +44,7 @@ on Met Office systems.
 +----------------------+----------------------------------------------------------+
 | all                  | The complete test suite. This is run automatically       |
 |                      | every night and monitored by the SSD team. All           |
-|                      | :ref:`KGO <kgo>` changing tickets need to run this group.|
+|                      | :ref:`KGO <kgo>` changing PRs need to run this group.    |
 +----------------------+----------------------------------------------------------+
 +----------------------+----------------------------------------------------------+
 | loobos               | A set of tests to exercise these science areas.          |

source/Development/TestSuites/lfric_apps.rst

@@ -50,7 +50,7 @@ groups, and that you can specify more than one at once, e.g.
 | all                | The complete test suite, including all longer runs and   |
 |                    | less commonly used configs. This is run automatically    |
 |                    | every week and monitored by the SSD team. All            |
-|                    | :ref:`KGO <kgo>` changing tickets need to run this group.|
+|                    | :ref:`KGO <kgo>` changing PRs need to run this group.    |
 +--------------------+----------------------------------------------------------+
 +--------------------+----------------------------------------------------------+
 | build              | Compile tasks for all applications and science areas     |

source/Development/TestSuites/multi-repo_testing.rst

@@ -4,11 +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 ticket 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,8 +2,8 @@ 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 tickets guidance
-<multirepo>`.
+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
 suites and box models see the `UKCA trac wiki

source/Development/TestSuites/um.rst

@@ -56,7 +56,7 @@ groups, and that you can specify more than one at once, e.g.
 | all                | The complete test suite, including all longer runs and   |
 |                    | less commonly used utilites. This is run automatically   |
 |                    | every week and monitored by the SSD team. All            |
-|                    | :ref:`KGO <kgo>` changing tickets need to run this group.|
+|                    | :ref:`KGO <kgo>` changing PRs need to run this group.    |
 +--------------------+----------------------------------------------------------+
 +--------------------+----------------------------------------------------------+
 | rigorous_compile   | A build-only group that will sense-check the code for a  |

source/Development/inputs.rst

@@ -102,9 +102,9 @@ 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 ticket with metadata changes, you
-  can load their metadata by adding ``-M /path/to/working_copy/rose-meta`` to
-  the ``rose-edit`` command.
+  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.
 
 
 Adding a new LFRic Metadata Section
@@ -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
-ticket, 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,8 +13,8 @@ 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
-tickets the expectation is that you, as the developer, will include updated
-KGO files as part of your branch.
+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
 to this area is restricted to members of the Simulation Systems and Deployment
@@ -25,16 +25,16 @@ the commit process.
 KGO Update Process
 ------------------
 
-Getting the process right for KGO changing tickets significantly helps get such
-changes onto ``main``. When preparing your change for review:
+Getting the process right for KGO changing pull requests significantly helps get
+such changes onto ``main``. When preparing your change for review:
 
 1. Run the ``all`` rose-stem group in order to make sure that all
    changes to answers have been found.
 
    * Include the :ref:`trac.log <traclog>` output from this testing in your
-     ticket summary.
+     pull request summary.
 
-2. Add the ``kgo`` keyword to your ticket.
+2. Add the ``kgo`` label to your pull request.
 
 .. tab-set::
 

source/Development/macros.rst

@@ -54,7 +54,9 @@ Within the file a blank upgrade macro will typically look like this:
 
 Note: The BEFORE_TAG should match the AFTER_TAG of the previous macro in the
 chain. So if this is not the first macro since the release then the BEFORE_TAG
-will be the version number with an added ticket number as well. For example:
+will be the version number with an added ticket number as well. For github
+developments, the ticket number can be either an Issue or PR number. For
+example:
 
 .. code-block:: python
 
@@ -137,8 +139,10 @@ It is expected that all metadata changes in LFRic Core will require change to
 the rose-apps in LFRic Apps, but changes to Apps must not affect Core.
 Therefore, the apply_macros script requires a working copy of LFRic Apps to
 work, but will source it's own copy of Core if required. If your only changes
-are to LFRic Core metadata, then you will require a linked LFRic Apps ticket
-and test branch, but potentially not a development branch.
+are to LFRic Core metadata, then you will require a linked LFRic Apps PR and
+test branch, but potentially not a development branch. In order to avoid
+potential ticket number clashes between LFRic Core and LFRic Apps, we recommend
+using LFRic Apps Issue/PR number for the macro tag.
 
 .. important::
 
@@ -190,5 +194,6 @@ Apps working copy). Core and Jules will default to reading the
 
 The ``vnXX.Y_tTTTT`` option must match the After Tag of your upgrade macro.
 When setting this, the version is the last released version of LFRic Apps. If
-it's a linked Apps-Core ticket, then set the ticket number as the one where
-the most metadata changes are being made.
+it's a linked Apps-Core PR, then set the ticket number based on the Apps
+Issue or PR. This avoids potential ticket number clashes between the
+repositories.

source/Development/metadata_guidance.rst

@@ -63,7 +63,7 @@ more details including what should be in `jules-shared
 <https://code.metoffice.gov.uk/trac/jules/wiki/SharingJULESmetadata#Whatsinjules-shared>`__
 and in `jules-standalone, jules-lfric or um-atmos
 <https://code.metoffice.gov.uk/trac/jules/wiki/SharingJULESmetadata#Whatsinjules-standalonejules-lfricorum-atmos>`__.
-When developing shared JULES metadata, you will need :ref:`linked tickets
+When developing shared JULES metadata, you will need :ref:`linked pull requests
 <multirepo>`. The metadata migration is currently dictated by LFRic porting of
 science, although the ultimate aim is to have a single source of truth.
 

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 ticket 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.
 
@@ -77,7 +77,7 @@ approvals to take place.
 
 **Is the code you need to alter on a single repository or is it spread over
 multiple repositories?** If it's over multiple repositories you need to use
-linked tickets. See :ref:`multirepo` for further details.
+linked pull requests. See :ref:`multirepo` for further details.
 
 **Does similar code functionality already exist in the model?** It's a good
 idea **not** to re-invent the wheel or have code duplication! Speaking to code
@@ -98,7 +98,7 @@ upgrade macro to include the switch into the upgraded configuration.
 vital to make sure your code changes work when switched **on** and give the
 same answer when the code is run over different processor configurations.
 Producing a quick plot or plots to show the impact of your code and including
-them on your ticket can aid your SciTech reviewer in showing that your code
+them on your pull request can aid your SciTech reviewer in showing that your code
 works properly.
 
 **Does the change need any new diagnostics to make sense of the code?** Many
@@ -124,6 +124,6 @@ intends to optimise code, be prepared to provide evidence of how things have
 improved.
 
 ..
-    Comment: Are there any more that can be thought of? These tickets will
+    Comment: Are there any more that can be thought of? These PRs will
     mostly be done by experienced developers and usually inside the Met
     Office.

source/Development/temp_logicals.rst

@@ -156,7 +156,7 @@ temporary logical should be removed from the code base.
 
 .. important::
 
-    Prior to a ticket containing a temporary logical being committed to
-    ``main``, the developers is expected to open a new ticket which removes the
+    Prior to a pull request containing a temporary logical being committed to
+    ``main``, the developer is expected to open a new Issue which removes the
     logical after a fixed period. This acts as an memory aid that the logical
     needs to be removed in due course.

source/FurtherDetails/coding_style.rst

@@ -327,8 +327,8 @@ S2. Headers
   same and thus it need not be repeated in the latter. If a ``MODULE``
   contains more than one subroutine then further descriptions are required.
 
-- History comments should not be included in the header or routine code. FCM
-  TRAC provides the history of our codes.
+- History comments should not be included in the header or routine code. Version
+  control provides the history of our codes.
 
 - Code author names should NOT be included explicitly within the code as they
   quickly become out of date and are sometimes misleading. Instead we

source/FurtherDetails/dos_donts.rst

@@ -10,27 +10,25 @@ Please Do
 mitigate problems early on. This is the most common root cause of problems,
 sometimes years later.
 
-**Plan** your work aimed at the ``main`` across single or multiple tickets:
-    * Ensure tickets are not too big or small.
-    * Coherent parts of the overall change are contained in a single ticket
-    * Consider using an overarching ticket to link everything together
+**Plan** your work aimed across single or multiple Issues and Pull Requests:
 
-**Document your work** using tickets, TRAC pages, :ref:`formal documentation
+    * Each pull request should contain a single coherent change.
+    * Consider using an overarching issue to link everything together
+
+**Document your work** using Issues and pull requests, :ref:`formal documentation
 <docs>` and code comments. These help others and your future-self understand
 your work.
 
-**Meaningful names** for tickets, branches and variables. These help others and
-your future-self understand your work. "My_Branch", "Fix" are not helpful.
+**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.
 
 **Be considerate** of other users/developers. Their skill-sets and working days
 may be very different to yours. All changes are visible to all users
 worldwide.
 
-**Keep the ticket status up to date.** This enables the Simulation Systems and
-Deployment Team to monitor the progress of your ticket and potential
-conflicts.
-
-**Link to tickets in other MOSRS repositories**, eg jules:#1, ukca:#72
+**Link to issues/pull requests in other repositories**, eg ``MetOffice/jules#1``,
+``MetOffice/ukca:#72``
 
 Please Do Not
 -------------
@@ -47,12 +45,5 @@ has been developed under a different license without agreement from the
 Simulation Systems and Deployment Team. This includes lifting Fortran code or
 text from books. Our repositiories must not infringe copyright.
 
-**Add or link to old code** or tickets that predate MOSRS, for example...
-
-* Link to tickets in old internal repositories- links will either not resolve
-  or be incorrect
-* Add a version of the UM code older than UM 9.2 as a branch to the UM
-  repository
-
-**Request support by raising a ticket**. Newly raised tickets are not
+**Request support by raising an issue**. Newly raised issues are not
 monitored. Use the appropriate :ref:`support` channels.

source/FurtherDetails/glossary.rst

@@ -10,35 +10,21 @@ Closed Release:
     this way, and the rest free for changes.
 
 Code Review Deadline:
-    The date by which all tickets aiming to be included in a release have been
+    The date by which all pull requests aiming to be included in a release have been
     moved into code review.
 
-Colon Keyword:
-    The formatting pattern for certain ticket keywords. For example CR:user to
-    indicate that "user" will be performing the Code System Review.
-
 CodeSys Review:
-    A technical review of the changes involved in the ticket, 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 Systems and Deployment Team. Once a review has been approved
-    the Code Systems Reviewer is then responsible for committing the change to
-    the ``main``.
-
-..
-    or the Core Capability Development Team (for LFRic only reviews).
+    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 ``main``.
 
 Development Window:
     The period of time between the release of one software version and the code
     review deadline for the following release in which new developments are
     accepted for review.
 
-Further Commit:
-    Where a problem is found with a ticket after it has been committed, any
-    additional commits needed are associated with the same ticket and labelled
-    as a "Further Commit". Only essential and immediate fixes are treated this
-    way.
-
 Known Good Output (KGO):
     In order to verify that the model output hasn't been modified by a set of
     changes the test suite contains a stored set of output as a reference.
@@ -50,14 +36,15 @@ Head of ``Main``:
     when the work being done *has* to be built on top of changes already made
     since the last revision.
 
-Linked Ticket:
-    Work that spans two or more repositories, requiring tickets that should be
-    treated together and committed as a group.
+Linked Pull Request (Linked PR):
+    Work that spans two or more repositories, requiring pull requests that
+    should be treated together and committed as a group.
 
-Overarching Ticket:
-    Where a piece of work has been split into multiple sections and tickets an
-    extra ticket can be used to track this work. It should be closed when the
-    whole arc has been completed.
+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. 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

@@ -78,10 +78,10 @@ of model evolution.
 Sci/Tech Reviewer
 -----------------
 
-A Sci/Tech reviewer is assigned for every ticket 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.
+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
 SciTech review guidance.
@@ -95,8 +95,9 @@ most relevant code owner.
 Code Reviewer
 -------------
 
-The Code Reviewer performs the 2nd stage of review for every ticket. Further
-details are described in the :ref:`Code Reviewers Guide<code_review>`.
+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
 Review guidance.