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 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>`.
 
 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 tickets guidance
+with both the UM and LFRic by following the :ref:`linked PRs guidance
 <multirepo>`.
 
 For further guidance on testing and working with UKCA, including standard

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,7 +102,7 @@ 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
+  If you have a linked LFRic Core or Jules PR 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
-ticket, other than any import statements, which should point at vnX.Y or HEAD
+PR, 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
-tickets the expectation is that you, as the developer, will include updated
+PRs 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
@@ -25,16 +25,16 @@ the commit process.
 KGO Update Process
 ------------------
 
-Getting the process right for KGO changing tickets significantly helps get such
+Getting the process right for KGO changing PRs significantly helps get such
 changes onto the trunk. 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.
+     PR summary.
 
-2. Add the ``kgo`` keyword to your ticket.
+2. Add the ``kgo`` label to your PR.
 
 .. 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 PRs
 <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 PR 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 PRs. 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 PR 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 the
-    trunk, the developers is expected to open a new ticket which removes the
+    Prior to a PR containing a temporary logical being committed to the
+    trunk, the developers 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,53 +10,36 @@ Please Do
 mitigate problems early on. This is the most common root cause of problems,
 sometimes years later.
 
-**Plan** your work aimed at the trunk 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 PRs pages, :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, PRs, 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/PRs in other repositories**, eg ``MetOffice/jules#1``,
+``MetOffice/ukca:#72``
 
 Please Do Not
 -------------
 
-**Do not use svn commands.** Please use `FCM
-<http://metomi.github.io/fcm/doc/user_guide/>`__ for all development work.
-
-**Do not merge the trunk into your branch** for UM, JULES, UKCA and LFRic Apps
-changes as this breaks many aspects of how TRAC and fcm work. This will cause
-diffs to display incorrectly and causes database problems when merging.
-Instead, please create a head of trunk branch and merge in your old branch.
-
-**Do not develop using head of trunk branching if not needed.** Many aspects of
-the UM, JULES and UKCA workflows rely on version branching.
+**Do not develop using head of main branching if not needed.** Using version
+branching enables development of scientific suites, so please branch from a tag
+or the ``stable`` branch wherever possible.
 
 **Licensing** - Don't add code to any project (or to any branch thereof) that
 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 PRs 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
+    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
-    Simulation Systems and Deployment Team. Once a review has been approved
-    the Code Systems Reviewer is then responsible for committing the change to
-    the trunk.
-
-..
-    or the Core Capability Development Team (for LFRic only reviews).
+    Simulation IT Team. Once a review has been approved the Code Systems
+    Reviewer is then responsible for committing the change to the trunk.
 
 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,14 @@ Head of Trunk:
     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
+Linked PR:
+    Work that spans two or more repositories, requiring PRs 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.
 
 Regression:
     A set of tests that prove that a set of code changes have not degraded the

source/FurtherDetails/who.rst

@@ -79,7 +79,7 @@ of model evolution.
 Sci/Tech Reviewer
 -----------------
 
-A Sci/Tech reviewer is assigned for every ticket and comprises the first stage
+A Sci/Tech reviewer is assigned for every PR 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.
@@ -96,7 +96,7 @@ most relevant code owner.
 Code Reviewer
 -------------
 
-The Code Reviewer performs the 2nd stage of review for every ticket. Further
+The Code Reviewer performs the 2nd stage of review for every PR. 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