MetOffice · Jenny Hickson (jennyhickson) · Oct 30, 2025 · Oct 28, 2025 · Oct 29, 2025 · Oct 29, 2025
diff --git a/source/Development/TestSuites/lfric_apps.rst b/source/Development/TestSuites/lfric_apps.rst
@@ -16,7 +16,7 @@ Local testing:
 
     Alternatively, a single application can be built and run locally using
     `these instructions
-    <https://code.metoffice.gov.uk/trac/lfric_apps/wiki/local_builds>`__
+    <https://metoffice.github.io/lfric_apps/developer_guide/local_builds.html>`__
 
     This test does not use rose or cylc and is particularly useful for checking
     for compile errors while developing.

diff --git a/source/Development/TestSuites/lfric_core.rst b/source/Development/TestSuites/lfric_core.rst
@@ -31,10 +31,3 @@ developer suite).
 
 It is also possible to run on a single platform, eg. ``-z group=ex1a``. To
 select which meto EX machine is used, add ``-S USE_EX<AB/CD/Z>=true``.
-
-.. tip::
-
-    For more details on LFRic testing including details of unit tests please
-    visit the `LFRic testing trac wiki page
-    <https://code.metoffice.gov.uk/trac/lfric/wiki/LFRicTechnical/Testing>`__.
-
diff --git a/source/Development/documentation.rst b/source/Development/documentation.rst
@@ -36,9 +36,8 @@ alongside the code. This is then compiled using Sphinx into the webpages above.
 
     The UM documentation papers are written in LaTeX and stored in a separate
     repository. Guidelines for editing the UM documentation papers are available
-    `here <umdp>`_
+    :ref:`here <umdp>`.
 
-.._ umdp: https://code.metoffice.gov.uk/trac/um/wiki/WorkingPractices/Documentation/UpdatingUMDPs
 
 LFRic Apps and Core also use doxygen to document the code and all changes
 should include appropriate doxygen changes to go with them. Doxygen guidelines

diff --git a/source/Development/inputs.rst b/source/Development/inputs.rst
@@ -51,11 +51,6 @@ Rose GUI for users to switch it on. Additionally, sometimes the metadata needs
 to be modified without changing a namelist variable. Guidance for updating the
 metadata :ref:`is available <metadata_guidance>`.
 
-..
-  Could do with thinking about how the JULES metadata could be included in this
-  document in the future, rather than the JULES wiki page
-  (https://code.metoffice.gov.uk/trac/jules/wiki/WorkingPractices#NamelistsUpgradeMacrosMetadata)
-
 .. note::
 
     JULES developers also need to :doc:`update the JULES documentation

diff --git a/source/Development/metadata_guidance.rst b/source/Development/metadata_guidance.rst
@@ -53,16 +53,14 @@ have identical metadata regardless of the repository where they reside
 (e.g. UM).
 
 Shared JULES metadata is in the process of being migrated to
-`rose-meta/jules-shared
-<https://code.metoffice.gov.uk/trac/jules/browser/main/trunk/rose-meta/jules-shared>`__,
-which resides in the JULES repository. The sub-directories are imported
-by **rose-meta/um-atmos** and **rose-meta/jules-standalone** and is manually
-synced with a copy in LFRic. Please see `Sharing JULES metadata
-<https://code.metoffice.gov.uk/trac/jules/wiki/SharingJULESmetadata>`__ for
+``rose-meta/jules-shared``, in the JULES repository. The sub-directories are
+imported by **rose-meta/um-atmos** and **rose-meta/jules-standalone** and is
+manually synced with a copy in LFRic. Please see `Sharing JULES metadata
+<https://github.com/MetOffice/jules/wiki/sharing_jules_metadata>`__ for
 more details including what should be in `jules-shared
-<https://code.metoffice.gov.uk/trac/jules/wiki/SharingJULESmetadata#Whatsinjules-shared>`__
+<https://github.com/MetOffice/jules/wiki/sharing_jules_metadata#whats-in-jules-shared>`__
 and in `jules-standalone, jules-lfric or um-atmos
-<https://code.metoffice.gov.uk/trac/jules/wiki/SharingJULESmetadata#Whatsinjules-standalonejules-lfricorum-atmos>`__.
+<http://github.com/MetOffice/jules/wiki/sharing_jules_metadata#whats-in-jules-standalone_-jules-lfric-or-_um-atmos>`__.
 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.

diff --git a/source/Development/planning_your_change.rst b/source/Development/planning_your_change.rst
@@ -56,9 +56,8 @@ something wrong. Please do seek advice.
 coding standards and things to avoid, so it is useful for the developer to be
 aware of these.
 
-* `UMDP3 (UM and JULES FORTRAN)
-  <https://code.metoffice.gov.uk/doc/um/latest/umdp.html#003>`__
-* `LFRic Coding Styles
+* :ref:`Fortran Coding Styles <standards>`
+* `LFRic Coding Styles (which build on the above)
   <https://metoffice.github.io/lfric_core/how_to_contribute/index.html#how-to-contribute-index>`__
 * `PEP 8 (Python) <https://legacy.python.org/dev/peps/pep-0008/>`__
 

diff --git a/source/Development/rose_stem.rst b/source/Development/rose_stem.rst
@@ -78,8 +78,8 @@ manually configured, such as JULES.
 
             .. note::
 
-                LFRic Apps has a `detailed set of wiki pages
-                <https://code.metoffice.gov.uk/trac/lfric_apps/wiki/rose-stem>`__
+                LFRic Apps has a `detailed set of pages
+                <https://metoffice.github.io/lfric_apps/developer_guide/lfric_apps_rose_stem/index.html>`__
                 that document the structure and options available for their
                 suite.
 

diff --git a/source/Development/temp_logicals.rst b/source/Development/temp_logicals.rst
@@ -115,21 +115,7 @@ examining existing variables in the subroutines listed in the table above.
 
 An upgrade macro and Rose metadata will be required to add the temporary
 logical into the GUI and make it available to model users. See :ref:`inputs`
-for further information. UM developers are also expected to fill in a
-`temporary fixes summary template
-<https://code.metoffice.gov.uk/trac/um/wiki/PageTemplates/TempFixesSummary>`__
-and `the temporary logical table
-<https://code.metoffice.gov.uk/trac/um/wiki/TempUMlogicals>`__ prior to the
-review process.
-
-..
-    Note: Have we got a page on upgrade macros? (i.e. brief instructions on how
-    to write one?) I wonder if we need one - I can only see a discussion on
-    what they are and how to apply one!
-
-    Should the temporary logical page and the summary wiki page be extended to
-    all repositories? I can't see one for JULES at the moment. This is
-    something to think about making consistent.
+for further information.
 
 
 After the release cycle

diff --git a/source/Development/um_docs.rst b/source/Development/um_docs.rst
@@ -1,3 +1,5 @@
+.. _umdp:
+
 Unified Model Documentation Papers (UMDPs)
 ==========================================
 

diff --git a/source/FurtherDetails/coding_style.rst b/source/FurtherDetails/coding_style.rst
@@ -1,3 +1,5 @@
+.. _standards:
+
 ==================
 Software standards
 ==================

diff --git a/source/Reviewers/codereview.rst b/source/Reviewers/codereview.rst
@@ -110,16 +110,9 @@ will include areas such as:
     Generally this is about making sure the code complies with the relevant
     style guides, and is consistent with the design of the code it sits in.
 
-    * `UMDP3 (UM and JULES FORTRAN)
-      <https://code.metoffice.gov.uk/doc/um/latest/umdp.html#003>`__,
-    * `LFRic Coding Styles
-      <https://code.metoffice.gov.uk/trac/lfric/wiki/LFRicTechnical/CodingStandards>`__
-    * `PEP 8 (Python) <https://legacy.python.org/dev/peps/pep-0008/>`__
-
-    `This page
-    <https://code.metoffice.gov.uk/trac/um/wiki/CodeReviewCribSheet>`__
-    provides some common (though UM-centric) things to confirm and think
-    about. It is not an exhaustive list, just a starting point.
+    * :ref:`Fortran Coding Styles <standards>`
+    * `LFRic Coding Styles (which build on the above)
+      <https://metoffice.github.io/lfric_core/how_to_contribute/coding_standards/fortran_coding_standards.html>`__
 
 Final decision points and actions
 ---------------------------------

diff --git a/source/Reviewers/howtocommit.rst b/source/Reviewers/howtocommit.rst
@@ -116,9 +116,8 @@ To update the test suite for an upgrade macro, please run:
         .. note::
 
             The ``-\-jules-path`` option is only required if there are
-            linked `jules-shared
-            <https://code.metoffice.gov.uk/trac/jules/browser/main/trunk/rose-meta/jules-shared>`__
-            metadata changes.
+            linked changes to the ``rose-meta/jules-shared`` directory in the
+            Jules repository.
 
     .. tab-item:: JULES
 
@@ -187,10 +186,10 @@ To update the test suite for an upgrade macro, please run:
         this by checking out an appropriate working copy, and exporting the
         environment variable ``ROSE_META_PATH=/path/to/core``.
 
-        For UM PRs, if there are linked `jules-shared
-        <https://code.metoffice.gov.uk/trac/jules/browser/main/trunk/rose-meta/jules-shared>`__
-        metadata changes then a suitable Jules source will need to be included
-        in the `ROSE_META_PATH` as described above.
+        For UM PRs, if there are linked changes to the
+        ``rose-meta/jules-shared`` directory in the Jules repository, then a
+        suitable Jules source will need to be included in the `ROSE_META_PATH`
+        as described above.
 
 
 .. dropdown:: Temporary Logical?
@@ -434,7 +433,7 @@ KGO differently*
         #. Copy the new KGO to the correct locations:
 
             `JULES KGO commands
-            <https://code.metoffice.gov.uk/trac/jules/wiki/KGOInstall>`__
+            <https://github.com/MetOffice/git_playground/wiki/Jules-KGO-Instructions>`__
 
         #. Rerun the rose-stem tests to make sure nothing is broken.
 

diff --git a/source/Reviewers/releases/mule_release.rst b/source/Reviewers/releases/mule_release.rst
@@ -6,7 +6,7 @@ Mule Release
 .. note::
 
     Additional details for the shumlib/mule releases can be seen `here
-    <https://code.metoffice.gov.uk/trac/um/wiki/mule_shumlib_install_details>`__
+    <https://github.com/MetOffice/git_playground/wiki/Shumlib-and-Mule-Additional-Install-Details>`__
 
 
 Releasing Mule

diff --git a/source/Reviewers/releases/shumlib_release.rst b/source/Reviewers/releases/shumlib_release.rst
@@ -6,7 +6,7 @@ Shumlib Release
 .. note::
 
     Additional details for the shumlib/mule releases can be seen `here
-    <https://code.metoffice.gov.uk/trac/um/wiki/mule_shumlib_install_details>`__
+    <https://github.com/MetOffice/git_playground/wiki/Shumlib-and-Mule-Additional-Install-Details>`__
 
 
 Releasing Shumlib

diff --git a/source/Reviewers/scitechreview.rst b/source/Reviewers/scitechreview.rst
@@ -35,10 +35,10 @@ The Science / Technical reviewer should
 
 * Ensure that the code has no unwanted side-effects
 
-* Ensure that the code is written to the standards laid out in `UMDP3
-  <https://code.metoffice.gov.uk/doc/um/latest/papers/umdp_003.pdf>`__ or
-  `LFRic Coding Styles
-  <https://code.metoffice.gov.uk/trac/lfric/wiki/LFRicTechnical/CodingStandards>`__.
+* Ensure that the code is written to the standards laid out in
+  :ref:`Fortran Coding Standards <standards>` or `LFRic Coding Styles
+  <https://metoffice.github.io/lfric_core/how_to_contribute/coding_standards/fortran_coding_standards.html>`__
+  (which build on the first).
 
 * Make sure that the in-line documentation is accurate and sufficient.