diff --git a/source/FurtherDetails/who.rst b/source/FurtherDetails/who.rst
index b538481e..0a657201 100644
--- a/source/FurtherDetails/who.rst
+++ b/source/FurtherDetails/who.rst
@@ -80,8 +80,8 @@ 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 linked
-from the :ref:`Working Practices page<scitech>`. In some cases, the reviewer
+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
@@ -97,7 +97,7 @@ Code Reviewer
 -------------
 
 The Code Reviewer performs the 2nd stage of review for every ticket. Further
-details are described :ref:`Working Practices page<codereview>`.
+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.
diff --git a/source/Reviewers/codereview.rst b/source/Reviewers/codereview.rst
index 43d2ee47..9fdcc6d6 100644
--- a/source/Reviewers/codereview.rst
+++ b/source/Reviewers/codereview.rst
@@ -3,6 +3,13 @@
 Code and System Review
 ======================
 
+.. tip::
+
+  GitHub documentation on the review process and interface:
+  `Reviewing Proposed Changes in a Pull Request <https://docs.github.com/en/pull
+  -requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/
+  reviewing-proposed-changes-in-a-pull-request>`_
+
 Purpose of the review
 ---------------------
 The purpose of the code/system review is to analyse a change for its impact and
@@ -16,16 +23,17 @@ and should question anything that is poorly coded.
 Reviewer responsibilities and checkpoints
 -----------------------------------------
 
-The Code/System review template exists to help you think through all the areas
-of concern. A completed :ref:`review template <template>` should be appended
-to the ticket once you are finished.
+The pull request template that populates the pull request description box
+contains a Code Review section with questions to help you think through all the
+areas of concern. This Code Review section should be completed once you are
+finished.
 
 Work through the code review template considering each question in turn. These
 will include areas such as:
 
-.. dropdown:: Is the ticket and testing complete?
+.. dropdown:: Is the pull request and testing complete?
 
-    * A Ticket Summary should be attached and filled in. This includes:
+    * The Pull Request Template should be filled in. This includes:
         * Proof of :ref:`testing <testing>` completed. All tests should pass
           with the exception of any known changes in answers.
         * Approvals from the code owners for every file changed.
@@ -33,8 +41,8 @@ will include areas such as:
           affected configurations.
         * If the change modifies OMP code sections then approval from the
           optimisation team.
-    * It should be possible to understand the purpose of the ticket from the
-      details provided.
+    * It should be possible to understand the purpose of the pull request from
+      the details provided.
 
     .. tip::
 
@@ -45,7 +53,7 @@ will include areas such as:
 
     .. tip::
 
-        If the ticket has been completed by a non-Met Office developer it is
+        If the pull request has been completed by a non-Met Office developer it is
         useful to run tests ourselves early in the review process as different
         compilers may behave differently. It may also be necessary to run
         tests for systems that the partner has not had access to.
@@ -63,14 +71,14 @@ will include areas such as:
         * had the reconfiguration been altered? If so the UM testing must
           include the `recon` group
         * is there another rose-stem group that covers this area of code?
-          See :ref:`um_testing` for common examples
 
-.. dropdown:: Is this a :ref:`multi-repository<multirepo>` ticket?
+
+.. dropdown:: Is this a :ref:`multi-repository<multirepo>` pull request?
 
     Each of the repositories covered by these WPs have overlapping use of
     code.
 
-    The Ticket Summary/Code Review templates in each repository contain the
+    The pull request templates in each repository contain the
     details of when testing against other repositories are required. These
     highlight where the code is likely to interact. *e.g. if code in the
     shared/science folder in JULES is modified then both the UM and LFRIc Apps
@@ -78,19 +86,19 @@ will include areas such as:
 
     If this testing doesn't pass then either
 
-        a) the change in ticket will need modifying so that the parent
+        a) the change in pull request will need modifying so that the parent
         repository's test suite passes
 
-        b) this change requires a linked ticket in that repository so that all
-        tests can pass.
+        b) this change requires a linked pull request in that repository so that
+        all tests can pass.
 
     .. tip::
 
-        All linked tickets are reviewed as a group. Each ticket in the group
-        should contain links to all the others and the correct keywords
-        applied to make it easier to keep track of them all.
+        All linked pull requests are reviewed as a group. Each pull request in
+        the group should contain links to all the others and the correct
+        keywords applied to make it easier to keep track of them all.
 
-        Care is needed when :ref:`committing these tickets
+        Care is needed when :ref:`committing these pull requests
         <committinglinkedtickets>`.
 
 .. dropdown:: Is the code up to scratch?
@@ -112,16 +120,19 @@ will include areas such as:
 Final decision points and actions
 ---------------------------------
 
-The ticket will likely iterate between the reviewer and the developer during
-the review process while retaining it's code review status. However, the
-reviewer has the option to "reject and assign" back to the code author should
-the documentation or code not meet the required standards and major
-alterations/improvements are required. In this case the change will need a
-further SciTech review before it can be returned to the code reviewer.
+The pull request will likely iterate between the reviewer and the developer
+during the review process while retaining it's code review status. The Code
+Reviewer can `Resolve Conversations` when they feel each query has been
+satisfactorily answered.
+
+In the case where a reviewer believes a PR requires substantial changes to be
+made in order to reach sufficient quality for commit, the PR may be closed
+without merging. This will be done in consultation with the developer and other
+Code Owners and Reviewers.
 
-Once you are happy that the change is appropriate and correct, complete the
-approval section of the Code/System review template and change the ticket
-status to **approved**.
+Once you are happy that the change is appropriate and correct, and the code
+review parts of the pull request template have been completed, submit a
+review that `approves` the change.
 
-From here follow the :ref:`How To Commit<howtocommit>` guide through to ticket
+From here follow the :ref:`How To Commit<howtocommit>` guide through to pull request
 closure.
diff --git a/source/Reviewers/scitechreview.rst b/source/Reviewers/scitechreview.rst
index 9a1896d0..44d2af5b 100644
--- a/source/Reviewers/scitechreview.rst
+++ b/source/Reviewers/scitechreview.rst
@@ -3,6 +3,13 @@
 Science and Technical Review
 ============================
 
+.. tip::
+
+  GitHub documentation on the review process and interface:
+  `Reviewing Proposed Changes in a Pull Request <https://docs.github.com/en/pull
+  -requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/
+  reviewing-proposed-changes-in-a-pull-request>`_
+
 Purpose of the review
 ---------------------
 
@@ -12,9 +19,9 @@ performs, is standards compliant and well documented.
 Reviewer responsibilities and checkpoints
 -----------------------------------------
 
-The Sci/Tech review template exists to help you think through all the following
-areas. A completed :ref:`review template <template>` should be appended to the
-ticket once you are finished.
+The pull request template that populates the pull request description box
+contains a SciTech Review section with questions to help you think through all
+the areas of concern. This SciTech review section should be completed once you are finished.
 
 The Science / Technical reviewer should
 
@@ -33,11 +40,11 @@ The Science / Technical reviewer should
 * Ensure that any related :ref:`external documentation <docs>` is updated as
   necessary.
 
-* Check that the Trac ticket has been completed fully and accurately with
+* Check that the pull request has been completed fully and accurately with
   sufficient detail for others to understand the impact of the change.
 
 * Ensure that testing has been carried out satisfactorily (and recorded on the
-  Trac ticket), and that there is no impact for configurations outside the
+  pull request), and that there is no impact for configurations outside the
   required scope of the changeset.
 
 Final decision points and actions
@@ -46,13 +53,15 @@ Final decision points and actions
 The science/technical reviewer must demand that non-compliance is corrected
 before a change is passed onto the next level of review.
 
-The ticket will likely iterate between the reviewer and the developer during
-the review process while retaining it's sci/tech review status. However, the
-reviewer has the option to "reject and assign" back to the code author should
-the documentation or code not meet the required standards and major
-alterations/improvements are required.
+The pull request will likely iterate between the reviewer and the developer during
+the review process while retaining it's sci/tech review status.
+
+Once you are happy that the change is appropriate and correct, and the sci-tech
+review parts of the pull request template have been completed then change
+the review state to Code Review and leave an approving review.
+
+.. image:: ../WorkingPractices/images/gh_screenshots/project_scitech_light.png
+    :class: only-light border
 
-Once you are happy that the change is appropriate and correct, complete the
-approval section of the Sci/Tech review template and re-assign the ticket to
-the system/code reviewer. If need be ask the code author for the agreed
-system/code reviewer's name.
+.. image:: ../WorkingPractices/images/gh_screenshots/project_scitech_dark.png
+    :class: only-dark border.
diff --git a/source/WorkingPractices/approvals.rst b/source/WorkingPractices/approvals.rst
index 49edf01a..5dafb437 100644
--- a/source/WorkingPractices/approvals.rst
+++ b/source/WorkingPractices/approvals.rst
@@ -3,9 +3,10 @@
 Approval Process
 ================
 
-Every ticket will need to get approval from a group of people. These approvals
-are marked on the :ref:`Ticket Summary wiki pages <template>` by those signing
-off the approval.
+Every pull request will need to get approval from a group of people. Code Owner
+approvals are automatically requested when the pull request is marked as `Ready
+for Review`, while required Configuration Owner approvals will be listed on the
+trac.log testing summary.
 
 .. tip::
 
@@ -15,23 +16,12 @@ off the approval.
     You may need to chase up approvals occasionally. People are not perfect and
     remember to :ref:`be kind <code_of_conduct>`.
 
-.. tip::
-
-    From vn13.2 the :ref:`trac.log <traclog>` summary of your testing will also
-    list all the Code and Config Owner approvals required in a handy table to
-    make it easy to see what is required.
-
-.. note::
-
-    LFRic Apps does not yet have a formal Code Owner approval process. A list
-    of code owners is available and they should still be consulted as part of
-    your development.
-
 .. important::
 
     New UM Ancils must be submitted to the MIAO team for approval. Please
     follow their process for `Requesting New UM Ancils
-    <https://code.metoffice.gov.uk/trac/ancil/wiki/ANTS/ProjectManagement/updating_UMDIR>`__.
+    <https://code.metoffice.gov.uk/
+    trac/ancil/wiki/ANTS/ProjectManagement/updating_UMDIR>`__.
 
 Code Owners
 -----------
@@ -39,8 +29,12 @@ Code Owners
 Every file in the codebases has a :ref:`code_owner`, and every file changed
 will need checking by the code owners - no matter how small the change.
 
-A list of current code owners for each project can be found in
-``trunk/CodeOwners.txt``.
+A list of current code owners for each project can be found in the top level
+``CODEOWNERS`` file.
+
+Code Owners should complete a review requesting changes if needed, and
+approving once they are happy. They only need to review changes that fall in their
+area.
 
 .. Tip::
 
@@ -60,7 +54,7 @@ or RAL setup used operationally). Within the rose-stem testing these
 configurations will be used and any changes to the answers shown in testing
 will need sign off from the config owner.
 
-In some repositories, the code owner is supported by module leaders who will
+In JULES, the code owner is supported by module leaders who will
 sign-off scientifically significant changes to their areas of interest. The
 module leaders in this case will also act as configuration owners for their
 science settings.
@@ -69,9 +63,10 @@ A list of current config owners for the UM is found in
 ``trunk/ConfigOwners.txt``. Others are combined with the Code Owner lists
 above.
 
-Optimisation Approvals
-----------------------
+Other Approvals
+---------------
 
-Changes that modify code within an OpenMP section will require approval from
-the :ref:`hpc_opt_team`. Changes that modify or add PSyKAl-lite code will
-require approval from the TCD Team.
+There are other changes that require specific approval and these are made clear
+in the pull request description. For example, changes that modify code within an
+OpenMP section will require approval from the :ref:`hpc_opt_team` and changes
+that modify or add PSyKAl-lite code will require approval from the TCD Team.
diff --git a/source/WorkingPractices/images/gh_screenshots/project_scitech_dark.png b/source/WorkingPractices/images/gh_screenshots/project_scitech_dark.png
new file mode 100644
index 00000000..e94a431e
Binary files /dev/null and b/source/WorkingPractices/images/gh_screenshots/project_scitech_dark.png differ
diff --git a/source/WorkingPractices/images/gh_screenshots/project_scitech_light.png b/source/WorkingPractices/images/gh_screenshots/project_scitech_light.png
new file mode 100644
index 00000000..0094182b
Binary files /dev/null and b/source/WorkingPractices/images/gh_screenshots/project_scitech_light.png differ
diff --git a/source/WorkingPractices/images/gh_screenshots/review_cog_dark.png b/source/WorkingPractices/images/gh_screenshots/review_cog_dark.png
new file mode 100644
index 00000000..5fb5079d
Binary files /dev/null and b/source/WorkingPractices/images/gh_screenshots/review_cog_dark.png differ
diff --git a/source/WorkingPractices/images/gh_screenshots/review_cog_light.png b/source/WorkingPractices/images/gh_screenshots/review_cog_light.png
new file mode 100644
index 00000000..d9143d29
Binary files /dev/null and b/source/WorkingPractices/images/gh_screenshots/review_cog_light.png differ
diff --git a/source/WorkingPractices/pull_requests.rst b/source/WorkingPractices/pull_requests.rst
index 640357bc..977ea51c 100644
--- a/source/WorkingPractices/pull_requests.rst
+++ b/source/WorkingPractices/pull_requests.rst
@@ -7,6 +7,40 @@ Once you are happy with your development and the :ref:`test suites <testing>`
 pass then you are ready to pass your ticket to review. Reviews in github are
 done through pull requests.
 
+Changes will usually go through a 2-stage review process:
+
+1. SciTech review; carried out by someone that understands the area of code being
+   developed
+2. Code review; carried out by a member of the Simulation Systems Review Team
+
+Trivial pull requests are an exception and do not require a SciTech review.
+
+:ref:`Linked pull requests <linked>` will move through the review states together.
+
+.. tip::
+
+  Some things to consider when getting ready for review:
+
+  * If your development changes answers then make sure you have followed the
+    steps on :ref:`preparing a KGO ticket for review.<kgo>`
+
+  * Get in touch with your SciTech Reviewer before you feel ready for review.
+    They will have valuable insights into the code and, particularly for larger
+    changes, may appreciate the opportunity to look at your work as it
+    progresses.
+
+  * The review process will iterate between the developer and each reviewer
+    until the changes made are agreed to be of sufficient quality. This aims to
+    improve the quality of your change, considering a range of scientific and
+    technical aspects.The reviewer will fill in their section of the pull
+    request template which makes sure all aspects of the ticket are considered.
+
+  * Review suggestions and comments are formed into conversations. The `Resolve
+    Conversation` button is used by the reviewer when they are satisfied to
+    close that part of the review. The developer should **not** resolve
+    conversations themselves.
+
+
 Opening a Pull Request
 ----------------------
 
@@ -55,12 +89,17 @@ You have 4 options to consider.
     Make sure the base and compare branches are correct.
 
 Fill out the rest of the pull request by giving an appropriate title and
-supplying a description. The description box will contain a pull request
-template to fill out - this can be completed now, or edited later before
-passing to review.
+supplying a description:
+
+* The title will be used as the commit message and should be therefore be short
+  and succinct. It should not contain any issue or pull request numbers.
 
-Finally, ensure that the option to allow edits by maintainers is selected
-(see :ref:`reviewer_edits` for details).
+* The description box will contain a pull request template to fill out
+  including details of your change, any approvals needed, documentation
+  required and testing performed.
+
+Ensure that the option to allow edits by maintainers box
+is selected (see :ref:`reviewer_edits` for details).
 
 .. image:: images/gh_screenshots/maintainer_edit_light.png
     :class: only-light border
@@ -68,15 +107,21 @@ Finally, ensure that the option to allow edits by maintainers is selected
 .. image:: images/gh_screenshots/maintainer_edit_dark.png
     :class: only-dark border
 
+.. important::
+
+    If an issue exists for the work being completed then you should `link your
+    pull request with that issue. <https://docs.github.com/en/issues/
+    tracking-your-work-with-issues/using-issues/
+    linking-a-pull-request-to-an-issue>`_
+
+
+
 Once you are happy with the pull request details open the pull request.
 Initially you can choose to do this in draft mode, to allow you time to do any
-final fixes based on continuous integration. If you use draft mode mark the
-pull request as ``ready for review`` once you are satisfied.
+final fixes based on continuous integration. **If you use draft mode mark the
+pull request as ``ready for review`` once you are satisfied.**
 
-.. tip::
 
-    It is possible to `link your pull request with an issue
-    <https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue>`__
 
 Continuous Integration
 ----------------------
@@ -165,11 +210,96 @@ conflicts. Alternatively, you can do this from a terminal using git.
         If there are any merge conflicts you can now fix these using your
         conflict tool of choice.
 
+Selecting Reviewers
+-------------------
+
+There is a space in the pull request template to list the GitHub user ID of the
+scitech and code reviewers. Once these are filled in a GitHub Action will add
+this user as an ``assignee`` to the pull request.
+
+SciTech Review
+^^^^^^^^^^^^^^
+
+First refusal for completing the SciTech review should go to the main code
+owner(s) for the area affected. If they don't want to then they may have
+suggestions for other suitable reviewers or you can approach anyone who would
+have good insight into the changes made.
+
+Once you have found a reviewer add their GitHub user ID to the pull request
+description and request their review by clicking the cog on the `Reviewers`
+pane on the right of the pull request and selecting their name or GitHub user
+ID.
+
+.. image:: images/gh_screenshots/review_cog_light.png
+    :class: only-light border
+
+.. image:: images/gh_screenshots/review_cog_dark.png
+    :class: only-dark border
+
+Guidance for the SciTech reviewer can be found on the
+:ref:`SciTech review page <scitech_review>`.
+
+Code Review
+^^^^^^^^^^^
+
+Code reviewers are assigned by the Simulation Systems and Deployment Team from
+a pool of repository maintainers. New ``ready for review`` pull requests will be
+assigned a reviewer on a regular basis. If you need your pull request looking at
+more urgently than that, or think your pull request has been overlooked, then
+leave a comment for ``@ssdteam`` on the pull request.
+
+The assigned person will be listed in the pull request description and
+selected as a reviewer.  A label will also be added to the pull request to help
+track which pull requests are waiting for a code reviewer to be assigned.
+
+Guidance for the Code reviewer can be found on the
+:ref:`Code review page <code_review>`.
+
+.. _reviewer_edits:
+
+Code Reviewer Edits
+^^^^^^^^^^^^^^^^^^^
+
+As part of the process to commit certain tickets, code reviewers will sometimes
+need to commit changes to the branch of a developer. Common reasons for doing
+this include,
+
+* Updating KGO's
+* Applying upgrade macros
+* Updating commit hashes for linked tickets
+
+The ability to commit back to another users fork is only available to those with
+``maintainer`` access or above and they can only do so for branches with an open
+pull request and the ``Allow edits by maintainers`` option selected.
+
+
+Tracking Review Status
+----------------------
+
+All open pull requests will be added to a GitHub Project called
+``Review Tracker``. This is used to give pull requests a status that
+distinguishes between the different review states. Some states are achieved
+automatically, some require changing manually:
+
+* When the developer feels a PR is ready for the SciTech or Code Reviewer to
+  look at the state should be **manually** changed to ``SciTech Review`` or
+  ``Code Review`` as appropriate.
+
+* When the SciTech Review has been completed the state should be **manually**
+  changed to Code Review.
+
+.. image:: images/gh_screenshots/project_scitech_light.png
+    :class: only-light border
+
+.. image:: images/gh_screenshots/project_scitech_dark.png
+    :class: only-dark border
+
+Automatic changes include:
+
+* When changes are requested by a reviewer the state becomes ``Changes Requested``
+* When the pull request has been approved the state becomes ``Approved``
+* When the pull request has been merged, or otherwise closed, the state becomes
+  ``Done``
+
 
-Final Steps
------------
 
-Ensure that you have found a Sci/Tech reviewer and have had a Code reviewer
-assigned. See :ref:`reviews` for how to do this. If your pull request is in
-draft mode, you should now change it to active, indicating it is ready for
-review.
diff --git a/source/WorkingPractices/reviews.rst b/source/WorkingPractices/reviews.rst
deleted file mode 100644
index 8a463931..00000000
--- a/source/WorkingPractices/reviews.rst
+++ /dev/null
@@ -1,177 +0,0 @@
-.. _reviews:
-
-Reviews
-=======
-
-Changes will usually go through a 2-stage review process:
-
-#. SciTech review; carried out by someone that understands the area of code
-   being developed
-#. CodeSys review; carried out by a member of the Simulation Systems and
-   Deployment Team or the Core Capability Development Team
-
-Trivial tickets are an exception and do not require a SciTech review.
-
-:ref:`Linked tickets <linked>` will move through the review states together.
-
-.. note::
-
-    Expect some iteration with the reviewers. This aims to improve the quality
-    of your change, considering a range of scientific and technical aspects.
-    Normally, this process is indicated by ticket ownership changing whilst
-    maintaining the ticket status. By exception, if a change needs major
-    reworking, then it will be regressed to 'in progress'.
-
-.. tip::
-
-    Tickets included in a release are based on those in code review before the
-    code review deadline. Get ready for review with plenty of time to give
-    SciTech reviewers and the approvers time to do their jobs.
-
-.. important::
-
-    Get in touch with your SciTech Reviewer before you feel ready for review.
-    They will have valuable insights into the code and, particularly for
-    larger changes, may appreciate the opportunity to look at your work as it
-    progresses.
-
-.. important::
-
-    While your reviewers are in a good position to advise and make suggestions
-    on your changes it is also important that they are able to maintain an
-    impartial perspective, and therefore should not get involved in the
-    development.
-
-    In the case that a reviewer, either SciTech or Code, does get too involved
-    then another person should be brought in to finish the review process and
-    provide that external viewpoint.
-
-.. tip::
-
-    The reviewer will likely leave comments, all of which should be addressed
-    by the developer. The developer should **not** resolve these comments
-    themselves, instead allowing the reviewer to resolve them when they are
-    happy with the response.
-
-
-Preparing for Review
---------------------
-
-To help you get ready for review a :ref:`Ticket Summary <template>` should be
-attached to each ticket involved in your change. This will provide a checklist
-of things to consider including approvals, documentation and testing.
-Following this through completely makes a big difference to the review
-experience.
-
-Once you are happy that everything is in place then you are ready to continue
-to review.
-
-.. important::
-
-    If your development changes answers then make sure you have followed the
-    steps on :ref:`preparing a KGO ticket for review.<kgo>`
-
-    If you suspect there may be a change in answers but none have shown up
-    during testing then run the rose-stem ``all`` group to confirm this.
-
-.. Tip::
-
-    Check that your changes meet the coding standards for the codebase you are
-    working on:
-
-    * `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/>`_
-
-.. Tip::
-
-    Remember to follow all code-related steps and commit all your changes
-    before running final testing to avoid needing to re-run.
-
-.. Tip::
-
-    Sometimes you may wish to proceed with the reviews without all approvals in
-    place. Take a risk based approach and make sure the approvals are clearly
-    pending.
-
-    Some reasons to do this include:
-
-    * An approver and their deputy have not replied
-    * The outstanding approver is also one of the reviewers
-    * Time pressure combined with a low risk or complexity of ticket
-
-.. _scitech:
-
-Science/Technical Review
-------------------------
-
-The SciTech review is done by someone who is familiar with the area being
-changed to check that the change does what is says, in a sensible way, and
-doesn't do what it shouldn't. First refusal for completing the SciTech review
-should go to the main code owner(s) for the area affected. If they don't want
-to then they may have suggestions for other suitable reviewers or you can
-approach anyone who would have good insight into the changes made.
-
-Changes that have a linked LFRic Core ticket should find a SciTech reviewer
-from the CCD Team.
-
-The review process will iterate between the developer and reviewer until the
-changes made are agreed to be of sufficient quality. The SciTech reviewer will
-fill in a :ref:`SciTech Review Checklist <template>` which makes sure all
-aspects of the ticket are considered. Once the reviewer is satisfied, they
-will pass the ticket on to code/system review.
-
-Guidance for the SciTech reviewer can be found on the
-:ref:`SciTech review page <scitech_review>`.
-
-.. _codereview:
-
-Code and System Review
-----------------------
-
-Requesting a code reviewer is the responsibility of the developer and is done
-by emailing the :ref:`SSD Team <ssd>`. Reviewers are assigned to email
-requests a couple of times a week.
-
-The code reviewer will check that the change meets the coding standards and
-fits with the overall system design. They will also fill in a :ref:`Code
-Review Checklist <template>` to ensure that nothing is overlooked.
-
-Again, the review process is likely to be iterative between the code reviewer
-and the developer with the ticket ownership passing between the two while
-keeping the status as Code Review. If major changes are needed then the ticket
-may be rejected which will put it back to `In Progress` and a further SciTech
-Review will be needed in this case.
-
-Once the code reviewer is satisfied they will move the ticket into the
-``approved`` state, ready for commit to the trunk.
-
-Guidance for the code reviewer can be found on the
-:ref:`Code Review page <code_review>`.
-
-.. _reviewer_edits:
-
-Code Reviewer Edits
-^^^^^^^^^^^^^^^^^^^
-
-As part of the process to commit certain tickets, code reviewers will sometimes
-need to commit changes to the branch of a developer. Common reasons for doing
-this include,
-
-* Updating KGO's
-* Applying upgrade macros
-* Updating commit hashes for linked tickets
-
-The ability to commit back to another users fork is only available to those
-with ``maintainer`` access or above and they can only do so for branches with
-an open pull request and the ``Allow edits by maintainers`` option selected.
-
------
-
-.. _template:
-
-.. admonition:: todo
-
-    Check all references to the template reference defined here
diff --git a/source/WorkingPractices/working_practices.rst b/source/WorkingPractices/working_practices.rst
index 3e46a9d3..e7da224a 100644
--- a/source/WorkingPractices/working_practices.rst
+++ b/source/WorkingPractices/working_practices.rst
@@ -164,7 +164,6 @@ helpful for documenting and monitoring progress of your work.
     gh_dev_init
     multi_repository
     approvals
-    reviews
     pull_requests
     final_steps
     git_extras