diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
index d1e3c52fc4..ee361a4407 100644
--- a/.github/ISSUE_TEMPLATE/bug_report.md
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -7,26 +7,38 @@ assignees: ''
 
 ---
 
-# Description
+<!-- Please remove unwanted/unrelated/irrelevant information such as comments.
+Please copy any output files into a public Github gist (see https://gist.github.com/) and link to the gist, rather than relying on paths that might change. -->
 
-Provide a clear and concise description of the bug and what behavior you are expecting.
+Your bug may already be reported!
+Please search on the [Issue tracker](https://github.com/ufs-community/ufs-srweather-app/issues) before creating a new issue. 
+If an issue already exists, please use that issue to add any additional information.
 
-## Steps to Reproduce
+## Expected behavior
+<!-- Tell us what should happen. -->
 
-Please provide detailed steps for reproducing the issue.
+## Current behavior
+<!-- Tell us what happens instead of the expected behavior. -->
 
-1. step 1
-2. step 2
-3. see the bug...
+## Machines affected
+<!--- Please provide any relevant information about your setup, including machine/compiler combination. -->
+<!-- Reference other issues or PRs in other repositories that this issue is related to, and how they are related. -->
 
-## Additional Context
+## Steps To Reproduce
+<!--- Provide a link to a live example, a code snippet, and/or an explicit set of steps to reproduce this bug.
+1. Step 1
+2. Step 2
+3. See the bug... -->
 
-Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.
+## Detailed Description of Fix (optional)
+<!--- Provide a detailed description of the change or addition you are proposing. -->
 
-* Machine
-* Compiler
-* Reference other issues or PRs in other repositories that this is related to, and how they are related.
+## Additional Information (optional)
+<!-- Any other relevant information that we should know to correctly understand and reproduce the issue. 
+Please describe in as much detail as possible. -->
 
-## Output
+## Possible Implementation (optional)
+<!--- Suggest an idea for implementing addition or change. -->
 
-Please include any relevant log files, screenshots or other output here.
+## Output (optional)
+<!-- Please include any relevant log files, screenshots or other output here. -->
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
index c5f7619d81..05913d4ab1 100644
--- a/.github/ISSUE_TEMPLATE/feature_request.md
+++ b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -7,14 +7,35 @@ assignees: ''
 
 ---
 
+<!-- Please remove unwanted/unrelated/irrelevant information such as comments.
+Please copy any output files into a public Github gist (see https://gist.github.com/) 
+and link to the gist, rather than relying on paths that might change. -->
+
+Your issue may already be reported!
+Please search on the [Issue tracker](https://github.com/ufs-community/ufs-srweather-app/issues) before creating a new issue. If an issue already exists, please use that issue to add any additional information.
+
 ## Description
-Provide a clear and concise description of the problem to be solved.
+<!-- Provide a clear and concise description of the problem to be solved. -->
+<!-- What problem needs to be fixed? -->
+<!-- What new capability needs to be added? --> 
 
 ## Solution
-Add a clear and concise description of the proposed solution.
+<!-- Add a clear and concise description of the proposed solution. -->
+
+## Requirements**
+<!-- What does the new code need to accomplish? Does it require an update 
+to a version of software (e.g. modules of NCEPLibs, NetCDF, etc.), components 
+(e.g. UFS-Weather-Model), or system tools (e.g. python3) -->
+
+## Acceptance Criteria (Definition of Done)
+<!-- What does it mean for this feature to be finished? -->
 
-## Alternatives (optional)
-If applicable, add a description of any alternative solutions or features you've considered.
+## Dependencies (optional)
+<!-- Directly reference any issues or PRs in this or other repositories that this 
+issue is related to, and describe how they are related. -->
+<!-- Does this block progress on other issues? Add this issue as a dependency to 
+other issues as appropriate e.g. #IssueNumber has a dependency on this issue -->
 
-## Related to (optional)
-Directly reference any issues or PRs in this or other repositories that this is related to, and describe how they are related.
+## Alternative Solutions (optional)
+<!-- If applicable, add a description of any alternative solutions or features 
+you've considered. -->
diff --git a/.github/ISSUE_TEMPLATE/textonly_request.md b/.github/ISSUE_TEMPLATE/textonly_request.md
index e2be6bb5fe..2764d6a6d6 100644
--- a/.github/ISSUE_TEMPLATE/textonly_request.md
+++ b/.github/ISSUE_TEMPLATE/textonly_request.md
@@ -8,13 +8,13 @@ assignees: ''
 ---
 
 ## Description
-Provide a clear and concise description of the problem to be solved.
+<!-- Provide a clear and concise description of the problem to be solved. -->
 
 ## Solution
-Add a clear and concise description of the proposed solution.
+<!-- Add a clear and concise description of the proposed solution. -->
 
 ## Alternatives (optional)
-If applicable, add a description of any alternative solutions or features you've considered.
+<!-- If applicable, add a description of any alternative solutions or features you've considered. -->
 
 ## Related to (optional)
-Directly reference any issues or PRs in this or other repositories that this is related to, and describe how they are related.
+<!-- Directly reference any issues or PRs in this or other repositories that this is related to, and describe how they are related. -->
diff --git a/.github/PULL_REQUEST_TEMPLATE b/.github/PULL_REQUEST_TEMPLATE
index bad27f0f7e..d3c5a1b3e4 100644
--- a/.github/PULL_REQUEST_TEMPLATE
+++ b/.github/PULL_REQUEST_TEMPLATE
@@ -1,33 +1,91 @@
+
+- Update develop to head at ufs-community
+
 - Use this template to give a detailed message describing the change you want to make to the code.
 
-- You may delete any sections labeled "optional".
+- You may delete any sections labeled "optional" and any instructions within <!-- these sections -->.
+
+- If you are unclear on what should be written here, see https://github.com/wrf-model/WRF/wiki/Making-a-good-pull-request-message for some guidance and review the Code Contributor's Guide at https://github.com/ufs-community/ufs-srweather-app/wiki/Code-Manager's-Guide. 
 
-- If you are unclear on what should be written here, see https://github.com/wrf-model/WRF/wiki/Making-a-good-pull-request-message for some guidance. 
+- Code reviewers will assess the PR based on the criteria laid out in the Code Reviewer's Guide (https://github.com/ufs-community/ufs-srweather-app/wiki/Code-Manager's-Guide). 
 
-- The title of this pull request should be a brief summary (ideally less than 100 characters) of the changes included in this PR. Please also include the branch to which this PR is being issued.
+- The title of this pull request should be a brief summary (ideally less than 100 characters) of the changes included in this PR. Please also include the branch to which this PR is being issued (e.g., "[develop]: Updated UFS_UTILS hash").
 
 - Use the "Preview" tab to see what your PR will look like when you hit "Create pull request"
 
+
 # --- Delete this line and those above before hitting "Create pull request" ---
 
 ## DESCRIPTION OF CHANGES: 
-One or more paragraphs describing the problem, solution, and required changes.
+<!-- One or more paragraphs describing the problem, solution, and required changes. -->
+
+### Type of change
+<!-- Please delete options that are not relevant. Add an X to check off a box. -->
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
 
 ## TESTS CONDUCTED: 
-Explicitly state what tests were run on these changes, or if any are still pending (for README or other text-only changes, just put "None required". Make note of the compilers used, the platform/machine, and other relevant details as necessary. For more complicated changes, or those resulting in scientific changes, please be explicit!
+<!-- Explicitly state what tests were run on these changes, or if any are still pending (for README or other text-only changes, just put "None required"). Make note of the compilers used, the platform/machine, and other relevant details as necessary. For more complicated changes, or those resulting in scientific changes, please be explicit! -->
+<!-- Add an X to check off a box. -->
+
+- [ ] hera.intel
+- [ ] orion.intel
+- [ ] cheyenne.intel
+- [ ] cheyenne.gnu
+- [ ] gaea.intel
+- [ ] jet.intel
+- [ ] wcoss2.intel
+- [ ] NOAA Cloud (indicate which platform)
+- [ ] Jenkins
+- [ ] fundamental test suite
+- [ ] comprehensive tests (specify *which* if a subset was used)
 
 ## DEPENDENCIES:
-Add any links to external PRs (e.g. regional_workflow and/or UFS PRs). For example:
+<!-- Add any links to external PRs (e.g. regional_workflow and/or UFS PRs). For example:
 - ufs-community/regional_workflow/pull/<pr_number>
 - ufs-community/UFS_UTILS/pull/<pr_number>
-- ufs-community/ufs-weather-model/pull/<pr_number>
+- ufs-community/ufs-weather-model/pull/<pr_number> -->
 
 ## DOCUMENTATION:
-If this PR is contributing new capabilities that need to be documented, please also include updates to the RST files (docs/UsersGuide/source) as supporting material.
+<!-- If this PR is contributing new capabilities that need to be documented, please also include updates to the RST files (docs/UsersGuide/source) as supporting material. -->
+
+## ISSUE: 
+<!-- If this PR is resolving or referencing one or more issues, in this repository or elsewhere, list them here (Remember, issues must always be created before starting work on a PR branch!). For example, "Fixes issue mentioned in #123" or "Related to bug in https://github.com/ufs-community/other_repository/pull/63" -->
+
+## CHECKLIST
+<!-- Add an X to check off a box. -->
+- [ ] My code follows the style guidelines in the Contributor's Guide
+- [ ] I have performed a self-review of my own code using the Code Reviewer's Guide
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] My changes need updates to the documentation. I have made corresponding changes to the documentation
+- [ ] My changes do not require updates to the documentation (explain).
+- [ ] My changes generate no new warnings
+- [ ] New and existing tests pass with my changes
+- [ ] Any dependent changes have been merged and published
 
-## ISSUE (optional): 
-If this PR is resolving or referencing one or more issues, in this repository or elewhere, list them here. For example, "Fixes issue mentioned in #123" or "Related to bug in https://github.com/ufs-community/other_repository/pull/63"
+## LABELS (optional): 
+<!-- If you do not have permissions to add labels to your own PR, request that labels be added here. 
+Add an X to check off a box. Delete any unnecessary labels. -->
+A Code Manager needs to add the following labels to this PR: 
+- [ ] Work In Progress
+- [ ] bug
+- [ ] enhancement
+- [ ] documentation
+- [ ] release
+- [ ] high priority
+- [ ] run_ci
+- [ ] run_we2e_fundamental_tests
+- [ ] run_we2e_comprehensive_tests
+- [ ] Needs Cheyenne test 
+- [ ] Needs Jet test 
+- [ ] Needs Hera test 
+- [ ] Needs Orion test 
+- [ ] help wanted
 
 ## CONTRIBUTORS (optional): 
-If others have contributed to this work aside from the PR author, list them here
+<!-- If others have contributed to this work aside from the PR author, list them here -->
+
+
 
diff --git a/docs/UsersGuide/source/Components.rst b/docs/UsersGuide/source/Components.rst
index caccca06dc..fbe1cf910d 100644
--- a/docs/UsersGuide/source/Components.rst
+++ b/docs/UsersGuide/source/Components.rst
@@ -35,7 +35,10 @@ The prognostic atmospheric model in the UFS SRW Application is the Finite-Volume
 
 Supported model resolutions in this release include 3-, 13-, and 25-km predefined contiguous U.S. (:term:`CONUS`) domains, each with 127 vertical levels. Preliminary tools for users to define their own domain are also available in the release with full, formal support of these tools to be provided in future releases. The Extended Schmidt Gnomonic (ESG) grid is used with the FV3-LAM, which features relatively uniform grid cells across the entirety of the domain. Additional information about the FV3 dynamical core can be found in the `scientific documentation <https://repository.library.noaa.gov/view/noaa/30725>`__, the `technical documentation <https://noaa-emc.github.io/FV3_Dycore_ufs-v2.0.0/html/index.html>`__, and on the `NOAA Geophysical Fluid Dynamics Laboratory website <https://www.gfdl.noaa.gov/fv3/>`__.
 
-Interoperable atmospheric physics, along with various land surface model options, are supported through the Common Community Physics Package (CCPP), described `here <https://dtcenter.org/community-code/common-community-physics-package-ccpp>`__. Atmospheric physics are a set of numerical methods describing small-scale processes such as clouds, turbulence, radiation, and their interactions. There will be four physics suites supported for the SRW App v2.0.0 release. The first is the FV3_RRFS_v1beta physics suite, which is being tested for use in the future operational implementation of the Rapid Refresh Forecast System (RRFS) planned for 2023-2024, and the second is an updated version of the physics suite used in the operational Global Forecast System (GFS) v16. Additionally, FV3_WoFS and FV3_HRRR will be supported. A scientific description of the CCPP parameterizations and suites can be found in the `CCPP Scientific Documentation <https://dtcenter.ucar.edu/GMTB/v6.0.0/sci_doc/index.html>`__, and CCPP technical aspects are described in the `CCPP Technical Documentation <https://ccpp-techdoc.readthedocs.io/en/latest/>`__. The model namelist has many settings beyond the physics options that can optimize various aspects of the model for use with each of the supported suites. Additional information on Stochastic Physics options is available `here <https://stochastic-physics.readthedocs.io/en/release-public-v3/>`__.
+Interoperable atmospheric physics, along with various land surface model options, are supported through the Common Community Physics Package (CCPP), described `here <https://dtcenter.org/community-code/common-community-physics-package-ccpp>`__. Atmospheric physics are a set of numerical methods describing small-scale processes such as clouds, turbulence, radiation, and their interactions. There will be four physics suites supported for the SRW App v2.0.0 release. The first is the FV3_RRFS_v1beta physics suite, which is being tested for use in the future operational implementation of the Rapid Refresh Forecast System (RRFS) planned for 2023-2024, and the second is an updated version of the physics suite used in the operational Global Forecast System (GFS) v16. Additionally, FV3_WoFS_v0 and FV3_HRRR will be supported. A scientific description of the CCPP parameterizations and suites can be found in the `CCPP Scientific Documentation <https://dtcenter.ucar.edu/GMTB/v6.0.0/sci_doc/index.html>`__, and CCPP technical aspects are described in the `CCPP Technical Documentation <https://ccpp-techdoc.readthedocs.io/en/latest/>`__. The model namelist has many settings beyond the physics options that can optimize various aspects of the model for use with each of the supported suites. Additional information on Stochastic Physics options is available `here <https://stochastic-physics.readthedocs.io/en/release-public-v3/>`__.
+
+.. note::
+   SPP is currently only available for specific physics schemes used in the RAP/HRRR physics suite. Users need to be aware of which physics suite definition file (:term:`SDF`) is chosen when turning this option on. Among the supported physics suites, the full set of parameterizations can only be used with the ``FV3_HRRR`` option for ``CCPP_PHYS_SUITE``.
 
 The SRW App supports the use of both :term:`GRIB2` and :term:`NEMSIO` input data. The UFS Weather Model ingests initial and lateral boundary condition files produced by :term:`chgres_cube` and outputs files in netCDF format on a specific projection (e.g., Lambert Conformal) in the horizontal direction and model levels in the vertical direction.
 
diff --git a/docs/UsersGuide/source/ContributorsGuide.rst b/docs/UsersGuide/source/ContributorsGuide.rst
index 3e3437c0ff..e7b99f00f3 100644
--- a/docs/UsersGuide/source/ContributorsGuide.rst
+++ b/docs/UsersGuide/source/ContributorsGuide.rst
@@ -13,11 +13,11 @@ Background
 Authoritative branch
 -----------------------
 
-The main development branch for the ``ufs-srweather-app`` repository is ``develop``. The HEAD of ``develop`` reflects the latest development changes. It points to regularly updated hashes for individual sub-components, including the ``regional_workflow``. Pull requests (PRs) will be merged to ``develop``. 
+The ``ufs-srweather-app`` and ``regional_workflow`` repositories each maintain a main branch for development called ``develop``. The HEAD of ``develop`` reflects the latest development changes. It points to regularly updated hashes for individual sub-components. Pull requests (PRs) will be merged to ``develop``. 
 
 The ``develop`` branch is protected by the code management team:
     #. Pull requests for this branch require approval by at least two code reviewers.
-    #. A code manager should perform the review and the merge, but other contributors are welcome to provide comments/suggestions.
+    #. A code manager should perform at least one of the reviews and the merge, but other contributors are welcome to provide comments/suggestions.
 
 
 Code Management Team
@@ -27,67 +27,66 @@ Scientists from across multiple labs and organizations have volunteered to revie
 
 .. table::
 
-    +------------------+------------------------------------------------+
-    | **Organization** | **Reviewers**                                  |
-    +==================+================================================+
-    | EMC              | Chan-Hoo Jeon (@chan-hoo)                      |
-    |                  |                                                |
-    |                  | Ben Blake (@BenjaminBlake-NOAA)                |
-    |                  |                                                |
-    |                  | Ratko Vasic (@RatkoVasic-NOAA)                 |
-    +------------------+------------------------------------------------+
-    | EPIC             | Mark Potts (@mark-a-potts)                     |
-    |                  |                                                |
-    |                  | Jong Kim (@jkbk2004)                           |
-    |                  |                                                |                  
-    |                  | Natalie Perlin (@natalie-perlin)               |
-    |                  |                                                |
-    |                  | Gillian Petro (@gspetro-NOAA)                  |
-    |                  |                                                |
-    |                  | Edward Snyder (@EdwardSnyder-NOAA)             |
-    +------------------+------------------------------------------------+
-    | GLERL/UM         | David Wright (@dmwright526)                    |
-    +------------------+------------------------------------------------+
-    | GSL              | Jeff Beck (@JeffBeck-NOAA)                     |
-    |                  |                                                |
-    |                  | Gerard Ketefian (@gsketefian)                  |
-    |                  |                                                |
-    |                  | Linlin Pan (@panll)                            |
-    |                  |                                                |
-    |                  | Christina Holt (@christinaholtNOAA)            |
-    |                  |                                                |
-    |                  | Christopher Harrop (@christopherwharrop-noaa)  |
-    |                  |                                                |
-    |                  | Daniel Abdi (@danielabdi-noaa)                 |
-    +------------------+------------------------------------------------+
-    | NCAR             | Mike Kavulich (@mkavulich)                     |
-    |                  |                                                |
-    |                  | Will Mayfield (@willmayfield)                  |
-    +------------------+------------------------------------------------+
-    | NSSL             | Yunheng Wang (@ywangwof)                       |
-    +------------------+------------------------------------------------+
-
+    +------------------+------------------------------------------------+-----------------------------------------------------------------------------------+
+    | **Organization** | **Reviewers**                                  | **Areas of Expertise**                                                            |
+    +==================+================================================+===================================================================================+
+    | EMC              | Chan-Hoo Jeon (@chan-hoo)                      | Workflow, NCO requirements, and operational platform testing                      |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Ben Blake (@BenjaminBlake-NOAA)                | Output visualization, Rocoto                                                      |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Ratko Vasic (@RatkoVasic-NOAA)                 | Workflow, NCO requirements, and operational platform testing                      |
+    +------------------+------------------------------------------------+-----------------------------------------------------------------------------------+
+    | EPIC             | Mark Potts (@mark-a-potts)                     | HPC systems                                                                       |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Jong Kim (@jkbk2004)                           | UFS Weather Model configuration, forecast sensitivity analysis, data assimilation |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Natalie Perlin (@natalie-perlin)               | Generic Linux/Mac installations, hpc-stack/spack-stack                            |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Gillian Petro (@gspetro-NOAA)                  | Documentation                                                                     |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Edward Snyder (@EdwardSnyder-NOAA)             | WE2E testing, input data                                                          |
+    +------------------+------------------------------------------------+-----------------------------------------------------------------------------------+
+    | GLERL            | David Wright (@dmwright526)                    | FVCOM integration, output visualization, preprocessing tasks                      |
+    +------------------+------------------------------------------------+-----------------------------------------------------------------------------------+
+    | GSL              | Jeff Beck (@JeffBeck-NOAA)                     | SRW App configuration/workflow, code management, meteorological evaluation        |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Gerard Ketefian (@gsketefian)                  | ``regional_workflow`` scripts, jinja templates, and verification tasks            |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Linlin Pan (@panll)                            | Workflow, CCPP/physics, verification                                              |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Christina Holt (@christinaholtNOAA)            | Workflow, conda environment support, testing, and code management                 |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Christopher Harrop (@christopherwharrop-noaa)  | Rocoto, code management, and testing                                              |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Daniel Abdi (@danielabdi-noaa)                 | Workflow generation, testing RRFS on the cloud, environment modules               |
+    +------------------+------------------------------------------------+-----------------------------------------------------------------------------------+
+    | NCAR             | Mike Kavulich (@mkavulich)                     | CCPP/physics                                                                      |
+    |                  +------------------------------------------------+-----------------------------------------------------------------------------------+
+    |                  | Will Mayfield (@willmayfield)                  | Verification/METplus tasks, regional_workflow (esp. on Cheyenne)                  |
+    +------------------+------------------------------------------------+-----------------------------------------------------------------------------------+
+    | NSSL             | Yunheng Wang (@ywangwof)                       | HPC systems, code management and regional workflow especially on Stampede, Jet    |
+    |                  |                                                | and NSSL computers                                                                |
+    +------------------+------------------------------------------------+-----------------------------------------------------------------------------------+
 
 .. _ContribProcess:
 
 Contribution Process
 ========================
 
-The steps below should be followed in order to make changes to the ``develop`` branch of the ``ufs-srweather-app`` repository. Communication with code managers and the code management team throughout the process is encouraged.
+The steps below should be followed in order to make changes to the ``develop`` branch of the ``ufs-srweather-app`` or ``regional_workflow`` repositories. Communication with code managers and the code management team throughout the process is encouraged.
 
     #. **Issue** - Open an issue to document changes. Click `here <https://github.com/ufs-community/ufs-srweather-app/issues/new/choose>`__ to open a new ``ufs-srweather-app`` issue or see :numref:`Step %s <Issue>` for detailed instructions. 
     #. **GitFlow** - Follow `GitFlow <https://nvie.com/posts/a-successful-git-branching-model/>`__ procedures for development. 
     #. **Fork the repository** - Read more `here <https://docs.github.com/en/get-started/quickstart/fork-a-repo>`__ about forking in GitHub.
-    #. **Create a branch** - Create a branch in your fork of the authoritative repository. Follow `GitFlow <https://nvie.com/posts/a-successful-git-branching-model/>`__ conventions when creating the branch. Branches should be named as follows, where [name] is a one-word description of the branch:
+    #. **Create a branch** - Create a branch in your fork of the authoritative repository. Follow `GitFlow <https://nvie.com/posts/a-successful-git-branching-model/>`__ conventions when creating the branch. All development should take place on a branch, *not* on ``develop``. Branches should be named as follows, where [name] is a one-word description of the branch:
 
         * **bugfix/[name]:** Fixes a demonstrably incorrect portion of code
-        * **feature/[name]:** Adds a new feature to the code
-        * **enhancement/[name]:** Improves an existing portion of the code
-        * **textonly/[name]:** Changes elements of the repository that do not impact program output or log files (e.g., changes to README, documentation, comments, changing quoted Registry elements, white space alignment). Any change which does not impact the compiled code in any way should fall under this category.
+        * **feature/[name]:** Adds a new feature to the code or improves an existing portion of the code
+        * **text/[name]:** Changes elements of the repository that do not impact program output or log files (e.g., changes to README, documentation, comments, changing quoted Registry elements, white space alignment). Any change that does not impact the compiled code in any way should fall under this category.
          
-    #. **Development** - Perform and test changes in the branch. Document work in the issue and mention the issue number in commit messages to link your work to the issue (e.g., ``commit -m "Issue #23 - <commit message>"``). Test code modifications on as many platforms as possible, and request help with further testing from the code management team when unable to test on all platforms. Document changes to the workflow and capabilities (either in the ``.rst`` files or separately) so that the SRW App documentation stays up-to-date. 
-    #. **Pull request** - When ready to merge changes back to the ``develop`` branch, the code developer should initiate a pull request (PR) of the feature branch into the ``develop`` branch. Read `here <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests>`__ about pull requests in GitHub. When a PR is initiated, the :ref:`PR Template <Template>` autofills. Developers should use the template to provide information about the PR in the proper fields. See the guidelines in :numref:`Section %s <GoodPR>` for more details on making a good pull request. Developers should also tag all relevant reviewers from the code management team to the PR.
-    #. **Merge** - When review and testing is complete, a code manager will complete the pull request and subsequent merge. If the PR was issued by a code manager, that same code manager should perform the merge or explicitly delegate another code manager to do so. 
+    #. **Development** - Perform and test changes in the branch (not on ``develop``!). Document work in the issue and mention the issue number in commit messages to link your work to the issue (e.g., ``commit -m "Issue #23 - <commit message>"``). Test code modifications on as many platforms as possible, and request help with further testing from the code management team when unable to test on all Level 1 platforms. Document changes to the workflow and capabilities in the ``.rst`` files so that the SRW App documentation stays up-to-date. 
+    #. **Pull request** - When ready to merge changes back to the ``develop`` branch, the code developer should initiate a pull request (PR) of the feature branch into the ``develop`` branch. Read `here <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests>`__ about pull requests in GitHub. When a PR is initiated, the :ref:`PR Template <Template>` autofills. Developers should use the template to provide information about the PR in the proper fields. See the guidelines in :numref:`Section %s <GoodPR>` for more details on making a good pull request. Developers should also tag all relevant reviewers from the code management team on the PR.
+    #. **Merge** - When review and testing are complete, a code manager will merge the PR into the target branch (usually ``develop``). PRs that are not ready for merging should have a "Work in Progress" label on them. Users who lack the permissions required to add the label can request in their PR that a code manager do so. 
     #. **Cleanup** - After the PR is merged, the code developer should delete the branch on their fork and close the issue.
 
 .. note::
@@ -98,56 +97,107 @@ The steps below should be followed in order to make changes to the ``develop`` b
 Opening an Issue
 -------------------
 
-To open an issue, click on `New Issue <https://github.com/ufs-community/ufs-srweather-app/issues/new/choose>`__ within the ``ufs-srweather-app`` GitHub repository. 
+All changes should be associated with a GitHub Issue. If developers are working on a change, they should search the existing issues in the appropriate repository (``ufs-srweather-app`` and/or ``regional_workflow``). If an issue does not exist for the work they are doing, they should create one prior to opening a new pull request.
+
+To open an issue, click on `New Issue <https://github.com/ufs-community/ufs-srweather-app/issues/new/choose>`__ within the ``ufs-srweather-app`` GitHub repository and/or within the ``regional_workflow`` repository (depending on where the changes will be made). 
 
 Choose from three options: 
     #. `Bug Report <https://github.com/ufs-community/ufs-srweather-app/issues/new?assignees=&labels=bug&template=bug_report.md&title=>`__: Report specific problems ("bugs") in the code using the following template:
 
         .. code-block:: console
 
-            ## Description
-            Provide a clear and concise description of the bug and what behavior 
-            you are expecting.
+            <!-- Please remove unwanted/unrelated/irrelevant information such as comments.
+            Please copy any output files into a public Github gist (see https://gist.github.com/) and link to the gist, 
+            rather than relying on paths that might change. -->
+
+            Your bug may already be reported!
+            Please search on the [Issue tracker](https://github.com/ufs-community/ufs-srweather-app/issues) before creating 
+            a new issue. 
+            If an issue already exists, please use that issue to add any additional information.
+
+            ## Expected behavior
+            <!-- Tell us what should happen. -->
 
-            ## Steps to Reproduce
-            Please provide detailed steps for reproducing the issue.
+            ## Current behavior
+            <!-- Tell us what happens instead of the expected behavior. -->
 
-                1. step 1
-                2. step 2
-                3. see the bug...
+            ## Machines affected
+            <!--- Please provide any relevant information about your setup, including machine/compiler combination. -->
+            <!-- Reference other issues or PRs in other repositories that this issue is related to, and how they are related. -->
 
-            ## Additional Context
-            Please provide any relevant information about your setup. This is important in 
-            case the issue is not reproducible except for under certain conditions.
+            ## Steps To Reproduce
+            <!--- Provide a link to a live example, a code snippet, and/or an explicit set of steps to reproduce this bug.
+            1. Step 1
+            2. Step 2
+            3. See the bug... -->
 
-                * Machine
-                * Compiler
-                * Reference other issues or PRs in other repositories that this 
-                is related to, and how they are related.
+            ## Detailed Description of Fix (optional)
+            <!--- Provide a detailed description of the change or addition you are proposing. -->
 
-            ## Output
-            Please include any relevant log files, screenshots or other output here.
+            ## Additional Information (optional)
+            <!-- Any other relevant information that we should know to correctly understand and reproduce the issue. 
+            Please describe in as much detail as possible. -->
 
+            ## Possible Implementation (optional)
+            <!--- Suggest an idea for implementing addition or change. -->
+
+            ## Output (optional)
+            <!-- Please include any relevant log files, screenshots or other output here. -->
 
     #. `Feature Request <https://github.com/ufs-community/ufs-srweather-app/issues/new?assignees=&labels=enhancement&template=feature_request.md&title=>`__: New features and feature enhancements fall under this category. Propose features and enhancements using the following template. Optional sections may be deleted.
 
         .. code-block:: console
 
+            <!-- Please remove unwanted/unrelated/irrelevant information such as comments. 
+            Please copy any output files into a public Github gist (see https://gist.github.com/) and link to the gist, 
+            rather than relying on paths that might change. -->
+
+            Your issue may already be reported!
+            Please search on the [Issue tracker](https://github.com/ufs-community/ufs-srweather-app/issues) before creating 
+            a new issue. 
+            If an issue already exists, please use that issue to add any additional information.
+
+
+            ## Description
+            <!-- Provide a clear and concise description of the problem to be solved. -->
+            <!-- What problem needs to be fixed? -->
+            <!-- What new capability needs to be added? --> 
+
+            ## Solution
+            <!-- Add a clear and concise description of the proposed solution. -->
+
+            ## Requirements**
+            <!-- What does the new code need to accomplish? Does it require an update to a version of software 
+            (e.g., modules of NCEPLibs, NetCDF, etc.), components (e.g. UFS-Weather-Model), or system tools (e.g. python3) -->
+
+            ## Acceptance Criteria (Definition of Done)
+            <!-- What does it mean for this feature to be finished? -->
+
+            ## Dependencies (optional)
+            <!-- Directly reference any issues or PRs in this or other repositories that this issue is related to, 
+            and describe how they are related. -->
+            <!-- Does this block progress on other issues? Add this issue as a dependency to other issues as appropriate 
+            (e.g., #IssueNumber has a dependency on this issue) -->
+
+            ## Alternative Solutions (optional)
+            <!-- If applicable, add a description of any alternative solutions or features you've considered. -->
+
+    #. `Text-Only Changes <https://github.com/ufs-community/ufs-srweather-app/issues/new?assignees=&labels=textonly&template=textonly_request.md&title=>`__: Propose text-only changes using the "Text-only request" template. Optional sections may be deleted.
+
+         .. code-block:: console
+
             ## Description
-            Provide a clear and concise description of the problem to be solved.
+            <!-- Provide a clear and concise description of the problem to be solved. -->
 
             ## Solution
-            Add a clear and concise description of the proposed solution.
+            <!-- Add a clear and concise description of the proposed solution. -->
 
             ## Alternatives (optional)
-            If applicable, add a description of any alternative solutions or 
-            features you've considered.
+            <!-- If applicable, add a description of any alternative solutions or features you've considered. -->
 
             ## Related to (optional)
-            Directly reference any issues or PRs in this or other repositories 
-            that this is related to, and describe how they are related.
-
-    #. `Text-Only Changes <https://github.com/ufs-community/ufs-srweather-app/issues/new?assignees=&labels=textonly&template=textonly_request.md&title=>`__: Propose text-only changes using the "Text-only request" template. This template's content is the same as for the "Feature Request" template above. 
+            <!-- Directly reference any issues or PRs in this or other repositories that this is related to, 
+            and describe how they are related. -->
 
     #. `Other <https://github.com/ufs-community/ufs-srweather-app/issues/new>`__: Open a blank issue, and use the "Feature Request" template above as a starting point to describe the issue. 
 
@@ -158,16 +208,16 @@ For all issue reports, indicate whether this is an issue that you plan to work o
 Making a Pull Request
 ---------------------------
 
-All changes to the SRW App ``develop`` branch should be handled via GitHub’s “Pull Request” (PR) functionality from a branch in the developer’s fork. Developers must follow the template PR instructions (see :numref:`Step %s <Template>` below) and provide links to the relevant GitHub issue(s). They must also indicate which tests were run on which machines. 
+All changes to the SRW App ``develop`` branch should be handled via GitHub's “Pull Request” (PR) functionality from a branch in the developer's fork. Developers must follow the template PR instructions (see :numref:`Step %s <Template>` below) and provide links to the relevant GitHub issue(s). They must also indicate which tests were run on which machines. 
 
-Pull requests will be reviewed and approved by at least two code managers. When a PR has met the requirements and been approved by code reviewers, a code manager will merge the PR. 
+Pull requests will be reviewed and approved by at least two code reviewers, at least one of whom must be a code manager. When a PR has met the contribution and testing requirements and has been approved by two code reviewers, a code manager will merge the PR. 
 
 
 .. note::
 
-    * If a developer wants to make use of automated testing, any SRW App + regional_workflow dependencies must be opened in PRs from dependent branches of forks belonging to the same user.
+    * If a developer wants to make use of automated testing, any ``ufs-srweather-app`` + ``regional_workflow`` dependencies must be opened in PRs from dependent branches of forks belonging to the same user.
     * The ``Externals.cfg`` file should point to any dependent branches in ``regional_workflow`` (and other components, if necessary) while those branches are under review. Once the corresponding ``regional_workflow`` PR has been merged, the developer should update the references in their ``Externals.cfg`` file to reflect the appropriate hashes in the authoritative repositories. 
-    * Developers should mention in their ``ufs-srweather-app`` PR description that they are temporarily pointing to a branch/hash in their fork of ``regional_worklfow`` and that it will be updated once the corresponding ``regional_workflow`` PR is merged.
+    * Developers should mention in their ``ufs-srweather-app`` PR description that they are temporarily pointing to a branch/hash in their fork of ``regional_workflow`` and that it will be updated once the corresponding ``regional_workflow`` PR is merged.
 
 
 .. _Template:
@@ -180,73 +230,127 @@ Here is the template that is provided when developers click "Create pull request
 .. code-block:: console
     
     - Update develop to head at ufs-community
-    - Use this template to give a detailed message describing the change 
-    you want to make to the code.
-    - You may delete any sections labeled "optional".
+    - Use this template to give a detailed message describing the change you want to make to the code.
+    - You may delete any sections labeled "optional" and any instructions within <!-- these sections -->.
     - If you are unclear on what should be written here, see https://github.com/wrf-model/WRF/wiki/Making-a-good-pull-request-message 
-    for some guidance. 
-    - The title of this pull request should be a brief summary (ideally less than 100 
-    characters) of the changes included in this PR. Please also include the branch to 
-    which this PR is being issued.
+    for some guidance and review the Code Contributor's Guide
+    (https://github.com/ufs-community/ufs-srweather-app/wiki/Contributor's-Guide). 
+    - Code reviewers will assess the PR based on the criteria laid out in the Code Reviewer's Guide 
+    (https://github.com/ufs-community/ufs-srweather-app/wiki/Code-Manager's-Guide). 
+    - The title of this pull request should be a brief summary (ideally less than 100 characters) of the changes included 
+    in this PR. Please also include the branch to which this PR is being issued (e.g., "[develop]: Updated UFS_UTILS hash").
     - Use the "Preview" tab to see what your PR will look like when you hit "Create pull request"
 
     # --- Delete this line and those above before hitting "Create pull request" ---
 
     ## DESCRIPTION OF CHANGES: 
-    One or more paragraphs describing the problem, solution, and required changes.
+    <!-- One or more paragraphs describing the problem, solution, and required changes. -->
+
+    ### Type of change
+    <!-- Please delete options that are not relevant. Add an X to check off a box. -->
+    - [ ] Bug fix (non-breaking change which fixes an issue)
+    - [ ] New feature (non-breaking change which adds functionality)
+    - [ ] Breaking change (fix or feature that would cause existing functionality 
+          to not work as expected)
+    - [ ] This change requires a documentation update
 
     ## TESTS CONDUCTED: 
-    Explicitly state what tests were run on these changes, or if any are still pending 
-    (for README or other text-only changes, just put "None required". Make note of the 
+    <!-- Explicitly state what tests were run on these changes, or if any are still pending 
+    (for README or other text-only changes, just put "None required"). Make note of the 
     compilers used, the platform/machine, and other relevant details as necessary. For 
-    more complicated changes, or those resulting in scientific changes, please be explicit!
+    more complicated changes, or those resulting in scientific changes, please be explicit! -->
+    <!-- Add an X to check off a box. -->
+
+    - [ ] hera.intel
+    - [ ] orion.intel
+    - [ ] cheyenne.intel
+    - [ ] cheyenne.gnu
+    - [ ] gaea.intel
+    - [ ] jet.intel
+    - [ ] wcoss2.intel
+    - [ ] NOAA Cloud (indicate which platform)
+    - [ ] Jenkins
+    - [ ] fundamental test suite
+    - [ ] comprehensive tests (specify *which* if a subset was used)
 
     ## DEPENDENCIES:
-    Add any links to external PRs (e.g. regional_workflow and/or UFS PRs). For example:
+    <!-- Add any links to external PRs (e.g. regional_workflow and/or UFS PRs). For example:
     - ufs-community/regional_workflow/pull/<pr_number>
     - ufs-community/UFS_UTILS/pull/<pr_number>
-    - ufs-community/ufs-weather-model/pull/<pr_number>
+    - ufs-community/ufs-weather-model/pull/<pr_number> -->
 
     ## DOCUMENTATION:
-    If this PR is contributing new capabilities that need to be documented, please also 
-    include updates to the RST files (docs/UsersGuide/source) as supporting material.
-
-    ## ISSUE (optional): 
-    If this PR is resolving or referencing one or more issues, in this repository or 
-    elewhere, list them here. For example, "Fixes issue mentioned in #123" or "Related to 
-    bug in https://github.com/ufs-community/other_repository/pull/63"
+    <!-- If this PR is contributing new capabilities that need to be documented, please also 
+    include updates to the RST files (docs/UsersGuide/source) as supporting material. -->
+
+    ## ISSUE: 
+    <!-- If this PR is resolving or referencing one or more issues, in this repository or 
+    elsewhere, list them here (Remember, issues must always be created before starting work 
+    on a PR branch!). For example, "Fixes issue mentioned in #123" or "Related to 
+    bug in https://github.com/ufs-community/other_repository/pull/63" -->
+
+    ## CHECKLIST
+    <!-- Add an X to check off a box. -->
+    - [ ] My code follows the style guidelines in the Contributor's Guide
+    - [ ] I have performed a self-review of my own code using the Code Reviewer's Guide
+    - [ ] I have commented my code, particularly in hard-to-understand areas
+    - [ ] My changes need updates to the documentation. I have made corresponding changes 
+          to the documentation
+    - [ ] My changes do not require updates to the documentation (explain).
+    - [ ] My changes generate no new warnings
+    - [ ] New and existing tests pass with my changes
+    - [ ] Any dependent changes have been merged and published
+
+    ## LABELS (optional): 
+    <!-- If you do not have permissions to add labels to your own PR, request that labels be added here. 
+    Add an X to check off a box. Delete any unnecessary labels. -->
+    A Code Manager needs to add the following labels to this PR: 
+    - [ ] Work In Progress
+    - [ ] bug
+    - [ ] enhancement
+    - [ ] documentation
+    - [ ] release
+    - [ ] high priority
+    - [ ] run_ci
+    - [ ] run_we2e_fundamental_tests
+    - [ ] run_we2e_comprehensive_tests
+    - [ ] Needs Cheyenne test 
+    - [ ] Needs Jet test 
+    - [ ] Needs Hera test 
+    - [ ] Needs Orion test 
+    - [ ] help wanted
 
     ## CONTRIBUTORS (optional): 
-    If others have contributed to this work aside from the PR author, list them here
-
+    <!-- If others have contributed to this work aside from the PR author, list them here -->
 
 Additional Guidance
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-**TITLE:** The title should give code reviewers a clear idea of what the change will do in approximately 5-10 words. Some good examples from the past:
+**TITLE:** Titles should start with the target branch name in brackets and should give code reviewers a clear idea of what the change will do in approximately 5-10 words. Some good examples:
 
-    * Make thompson_mynn_lam3km ccpp suite available
-    * Fix module loads on Hera
-    * Add support for Rocoto with generic LINUX platform
+    * [develop] Make thompson_mynn_lam3km ccpp suite available
+    * [release/public-v2] Add a build_linux_compiler modulefile
+    * [develop] Fix module loads on Hera
+    * [develop] Add support for Rocoto with generic LINUX platform
 
 All of the above examples concisely describe the changes contained in the pull request. The title will not get cut off in emails and web pages. In contrast, here are some made-up (but plausible) examples of BAD pull request titles:
 
     * Bug fixes (Bug fixes on what part of the code?)
     * Changes to surface scheme (What kind of changes? Which surface scheme?)
 
-**DESCRIPTION OF CHANGES:** The first line of the description should be a single-line "purpose" for this change. Note the type of change (i.e., bug fix, feature, enhancement, text-only). Summarize the problem, proposed solution, and required changes. If this is an enhancement or new feature, describe why the change is important.
+**DESCRIPTION OF CHANGES:** The first line of the description should be a single-line "purpose" for this change. Note the type of change (i.e., bug fix, feature/enhancement, text-only). Summarize the problem, proposed solution, and required changes. If this is an enhancement or new feature, describe why the change is important.
 
-**DOCUMENTATION:** Developers should include documentation on new capabilities and enhancements by updating the appropriate ``.rst`` documentation files in their ``ufs-srweather-app`` fork prior to the PR. These documentation updates should be noted in the "Documentation" section of the PR message. If necessary, contributors may submit the ``.rst`` documentation in a subsequent PR. In these cases, the developers should include any existing documentation in the "Documentation" section of the initial PR message or as a file attachment to the PR. Then, the contributor should open an issue (see :numref:`Step %s <Issue>`) reflecting the need for official ``.rst`` documentation updates and include the issue number and explanation in the "Documentation" section of the initial PR template.
+**DOCUMENTATION:** Developers should include documentation on new capabilities and enhancements by updating the appropriate ``.rst`` documentation files in their fork prior to the PR. These documentation updates should be noted in the "Documentation" section of the PR message. If necessary, contributors may submit the ``.rst`` documentation in a subsequent PR. In these cases, the developers should include any existing documentation in the "Documentation" section of the initial PR message or as a file attachment to the PR. Then, the contributor should open an issue (see :numref:`Step %s <Issue>`) reflecting the need for official ``.rst`` documentation updates and include the issue number and explanation in the "Documentation" section of the initial PR template.
  
 
 Tips, Best Practices, and Protocols to Follow When Submitting a PR
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
+* **Label PR status appropriately.** If the PR is not completely ready to be merged, please add a "Work in Progress" label. Urgent PRs should be marked "high priority." All PRs should have a type label (e.g., "bug," "enhancement"). Labels can be added on the right-hand side of a submitted PR request by clicking on the gear icon beside "Labels" (below the list of reviewers). If users do not have the permissions to add a label to their PR, they should request in their PR description that a code manager add the appropriate labels. 
 * **Indicate urgency.** If a PR is particularly urgent, this information should be provided in the PR "Description" section, and multiple code management team members should be tagged to draw attention to this PR. After submitting the PR, a "high priority" label should be added to it (see below). 
 * **Indicate the scope of the PR.** If the PR is extremely minor (e.g., change to the README file), indicate this in the PR message. If it is an extensive PR, the developer should test it on as many platforms as possible and stress the necessity that it be tested on systems for which they do not have access.
 * **Clarify in the PR message where the code has been tested.** At a minimum, code should be tested on the platform where code modification has taken place. It should also be tested on machines where code modifications will impact results. If the developer does not have access to these platforms, this should be noted in the PR. 
 * **Follow separation of concerns.** For example, module loads are only handled in the appropriate modulefiles, Rocoto always sets the work directory, j-jobs make the work directory, and ex-scripts require the work directory to exist.
-* **Label PR status appropriately.** If the PR is not completely ready to be merged please add a “Work in Progress” label. Urgent PRs should be marked "high priority." All PRs should have a type label (e.g., "bug," "enhancement"). Labels can be added on the right-hand side of a submitted PR request by clicking on the gear icon beside "Labels" (below the list of Reviewers).
 * **Target subject matter experts (SMEs) among the code management team.** When possible, tag team members who are familiar with the modifications made in the PR so that the code management team can provide effective and streamlined PR reviews and approvals. Developers can tag SMEs by selecting the gear icon next to "Assignees" (under the Reviewers list) and adding the appropriate names. 
 * **Schedule a live code review** if the PR is exceptionally complex in order to brief members of the code management team on the PR either in-person or through a teleconference. Developers should indicate in the PR message that they are interested in a live code review if they believe that it would be beneficial. 
 
@@ -259,97 +363,99 @@ Code and Configuration Standards
 General
 -----------
 
-Platform-specific settings should be handled only through configuration and modulefiles, not in code or scripts.
+* Platform-specific settings should be handled only through configuration and modulefiles, not in code or scripts.
+* For changes to the ``scripts``, ``ush``, or ``jobs`` directories, developers should follow the `NCO Guidelines <https://www.nco.ncep.noaa.gov/idsb/implementation_standards/>`__ for what is incorporated into each layer. 
+* Developers should ensure that their contributions work with the most recent version of the ``ufs-srweather-app``, including all the specific up-to-date hashes of each subcomponent.
+* Modifications should not break any existing supported capabilities on any supported platforms.
+* Update the ``.rst`` documentation files where appropriate as part of the PR. The documentation files reside in ``ufs-srweather-app``, so changes to ``regional_workflow`` that require documentation need a corresponding PR to ``ufs-srweather-app``. If necessary, contributors may update the documentation in a subsequent PR. In these cases, the contributor should open an issue reflecting the need for documentation (see :numref:`Step %s <Issue>`) and include the issue number and explanation in the Documentation section of their initial PR. 
 
 SRW Application
 ------------------
 
 Externals.cfg
     * All externals live in a single ``Externals.cfg`` file.
-    * Externals should point only to authoritative repositories for the given code base.
+    * Only a single hash will be maintained for any given external code base. All externals should point to this static hash (not to the top of a branch). 
+    * All new entries in ``Externals.cfg`` must point only to authoritative repositories. In other words, entries must point to either a `UFS Community GitHub organization <https://github.com/ufs-community>`__ repository or another NOAA project organization repository. 
 
         * Temporary exceptions are made for a PR into the ``develop`` branch of ``ufs-srweather-app`` that is dependent on another PR (e.g., a ``regional_workflow`` PR from the same contributor). When the component PR is merged, the contributor must update the corresponding ``ufs-srweather-app`` PR with the hash of the component's authoritative repository.
-    * Only a single hash will be maintained for any given external code base. All externals should point to this static hash (not to the top of a branch). 
+    
     
 Build system
-    * Each component should build with CMake
-    * Each component should build with Intel compilers on official `Level 1 <https://github.com/ufs-community/ufs-srweather-app/wiki/Supported-Platforms-and-Compilers>`__ platforms and with GNU or Intel compilers on other platforms. 
-    * Each component should have a mechanism for platform independence (i.e., no hard-coded machine-specific settings outside of established environment, configuration, and modulefiles). 
-    * Each component should build with the latest release of the `HPC-Stack <https://github.com/NOAA-EMC/hpc-stack>`__. 
+    * Each component must build with CMake
+    * Each component must build with Intel compilers on official `Level 1 <https://github.com/ufs-community/ufs-srweather-app/wiki/Supported-Platforms-and-Compilers>`__ platforms and with GNU or Intel compilers on other platforms. 
+    * Each component must have a mechanism for platform independence (i.e., no hard-coded machine-specific settings outside of established environment, configuration, and modulefiles). 
+    * Each component must build using the standard supported NCEPLIBS environment (currently `HPC-Stack <https://github.com/NOAA-EMC/hpc-stack>`__).
 
 Modulefiles
-    * Each component should build using the common modules located in the ``modulefiles/srw_common`` file.
+    * Each component must build using the common modules located in the ``modulefiles/srw_common`` file.
 
 
 Regional Workflow
 ----------------------
-The ``regional_workflow`` repository must not contain source code for compiled programs. Only scripts, configuration files, and documentation should reside in this repository. 
+If changes are made to ``regional_workflow``, a corresponding PR to ``ufs-srweather-app`` should be opened to update the ``regional_workflow`` hash.
 
 **General Coding Standards:** 
+    * The ``regional_workflow`` repository must not contain source code for compiled programs. Only scripts and configuration files should reside in this repository. 
     * All bash scripts must explicitly be ``#!/bin/bash`` scripts. They should *not* be login-enabled (i.e., scripts should *not* use the ``-l`` flag).
     * MacOS does not have all Linux utilities by default. Developers should ensure that they do not break any MacOS capabilities with their contribution.
     * All code must be indented appropriately and conform to the style of existing scripts (e.g., local variables should be lowercase, global variables should be uppercase).
 
 **Python Coding Standards:** 
     * All Python code contributions should come with an appropriate ``environment.yaml`` file for the feature. 
-    * Keep the use of external Python packages to a minimum for necessary workflow tasks. Currently, the required external Python packages are: ``f90nml``, ``pyyaml``, and ``jinja``. 
+    * Keep the use of external Python packages to a minimum for necessary workflow tasks. Currently, the required external Python packages are: ``f90nml``, ``pyyaml``, and ``Jinja2``. 
 
 **Workflow Design:** Follow the `NCO Guidelines <https://www.nco.ncep.noaa.gov/idsb/implementation_standards/>`__ for what is incorporated in each layer of the workflow. This is particularly important in the ``scripts`` directory. 
 
 **Modulefiles:** All official platforms should have a modulefile that can be sourced to provide the appropriate python packages and other settings for the platform. 
 
-**Management of the Configuration File:** New configurable options must be consistent with existing configurable options and documented in ``docs/UsersGuide/source/ConfigWorkflow.rst``. Add necessary checks on acceptable options where applicable. Add appropriate default values in ``config_defaults.sh``.
-
-**Management of Template Files:** If a new configurable option is required in an existing template, it must be handled similarly to its counterparts in the scripts that fill in the template.
-
-**Namelist Management:** Namelists in ``ufs-srweather-app`` and ``regional_workflow`` are generated using a Python tool and managed by setting YAML configuration parameters. This allows for the management of multiple configuration settings with maximum flexibility and minimum duplication of information. 
-
-
+**Management of the Configuration File:** New configurable options must be consistent with existing configurable options and be documented in ``ufs-srweather-app/docs/UsersGuide/source/ConfigWorkflow.rst``. Add necessary checks on acceptable options where applicable. Add appropriate default values in ``config_defaults.sh``.
 
-Contributor Requirements
-===========================
-
-Preparing Code for Contribution to the UFS SRW Application
-------------------------------------------------------------
-
-All changes should be associated with a GitHub Issue. If developers are working on a change, they should search the existing issues in the appropriate repository (``ufs-srweather-app`` and/or ``regional_workflow``). If an issue does not exist for the work they are doing, they should create one prior to opening a new pull request (see :numref:`Step %s <Issue>`).
-
-**Guidelines for All Modifications:**
-    * All changes should adhere to the Code and Configuration Standards detailed in :numref:`Section %s <ContribStandards>`. 
-    * For changes to the ``scripts``, ``ush``, or ``jobs`` directories (within ``ufs-srweather-app/regional_workflow``), developers should follow the `NCO Guidelines <https://www.nco.ncep.noaa.gov/idsb/implementation_standards/>`__ for what is incorporated into each layer. 
-    * Developers should ensure that their contributions work with the most recent version of the ``ufs-srweather-app``, including all the specific up-to-date hashes of each subcomponent.
-    * Modifications should not break any existing supported capabilities on any supported platforms.
-    * Developers will not be required to run tests on *all* supported platforms, but if a failure is pointed out by another reviewer (or by automated testing), then the developer should work with reviewers and code managers to ensure that the problem is resolved prior to merging.
-    * If possible, developers should run a fundamental test suite (see :numref:`Section %s <Testing>`) on at least one supported platform and report on the outcome in the PR template.
-    * If changes are made to ``regional_workflow``, a corresponding PR to ``ufs-srweather-app`` should be opened to update the ``regional_workflow`` hash. 
-    * Update the ``.rst`` documentation files where appropriate as part of the PR. If necessary, contributors may update the documentation in a subsequent PR. In these cases, the contributor should open an issue reflecting the need for documentation (see :numref:`Step %s <Issue>`) and include the issue number and explanation in the Documentation section of the initial PR template. 
-
-**Guidelines for New Features:**
-    * Components should have a mechanism for portability and platform-independence; code that is included in the SRW App should not be tied to specific platforms. 
-    * New components should be able to build using the standard supported NCEPLIBS environment (currently `HPC-Stack <https://github.com/NOAA-EMC/hpc-stack>`__).
-    * New entries in ``Externals.cfg`` should only be repositories from “official” sources; either the `UFS Community GitHub organization <https://github.com/ufs-community>`__ or another NOAA project organization.
-    * Document how to use the new component, and include this information in the PR. 
+**Management of Template Files:** If a new configurable option is required in an existing template, it must be handled similarly to its counterparts in the scripts that fill in the template. For example, if a new type of namelist is introduced for a new application component, it should make use of the existing ``jinja`` framework for populating namelist settings.
 
+**Namelist Management:** Namelists in ``ufs-srweather-app`` and ``regional_workflow`` are generated using a Python tool and managed by setting YAML configuration parameters. This allows for the management of multiple configuration settings with maximum flexibility and minimum duplication of information.     
 
 .. _Testing: 
 
 Testing
 ===============
 
-The ``ufs-srweather-app`` repository uses the established workflow end-to-end (WE2E) testing framework (see :numref:`Chapter %s <WE2E_tests>`) to implement two tiers of testing: fundamental and comprehensive. *Fundamental testing* consists of a lightweight set of tests that can be automated and run regularly on each `Level 1 <https://github.com/ufs-community/ufs-srweather-app/wiki/Supported-Platforms-and-Compilers>`__ platform. These are mostly low-resolution tests and cover a wide scope of capabilities to ensure that there are no major, obvious faults in the underlying code. *Comprehensive testing* involves a broader range of capabilities, configurations, and components. 
+The ``ufs-srweather-app`` repository uses the established workflow end-to-end (WE2E) testing framework (see :numref:`Chapter %s <WE2E_tests>`) to implement two tiers of testing: fundamental and comprehensive. **Fundamental testing** consists of a lightweight set of tests that can be automated and run regularly on each `Level 1 <https://github.com/ufs-community/ufs-srweather-app/wiki/Supported-Platforms-and-Compilers>`__ platform. These tests verify that there are no major, obvious faults in the underlying code when running common combinations of grids, input data, and physics suites. **Comprehensive testing** includes the entire set of WE2E tests and covers a broader range of capabilities, configurations, and components. Eventually, new tests will be added, including regression tests and unit tests. 
 
 Before opening a PR, a minimum set of tests should be run: 
-    * At least one end-to-end test (preferably a fundamental test suite) should be run on at least one supported platform
-    * Any new functionality should be tested explicitly, and tests should be described in detail in the PR message. Depending on the impact of this functionality, this test should be added to the WE2E suite of fundamental or comprehensive tests. 
+    * Developers should run the fundamental test suite manually on at least one supported platform and report on the outcome in the PR template (see :numref:`Section %s <Testing>`). 
+      
+      * Developers will not be required to run tests on *all* supported platforms, but if a failure is pointed out by another reviewer (or by automated testing), then the developer should work with reviewers and code managers to ensure that the problem is resolved prior to merging.
+    
+    * If the PR impacts functionality contained within comprehensive WE2E tests not included in the fundamental test suite, the developer must run those tests on the PR.
+    * Any new functionality must be tested explicitly, and any new tests should be described in detail in the PR message. Depending on the impact of this functionality, new tests should be added to the suite of comprehensive WE2E tests, followed by a discussion with code managers on whether they should also be included as fundamental tests.
+    
+      * In some cases, it may be possible to modify a current test instead of creating a completely new test. Code developers introducing new capabilities should work with code managers to provide the proper configuration files, data, and other information necessary to create new tests for these capabilities.
+
+    * **Coming Soon:** When the above tests are complete, a code manager will add the ``run_we2e_comprehensive_tests`` to initiate fundamental testing on all Level 1 platforms via Jenkins (see :ref:`below <jenkins>`).
+
+
+.. _jenkins:
 
-**Updating the Testing Suite:** When new capabilities are added or new bugs/issues are discovered, WE2E tests should be created and/or modified to verify that new features are not broken in subsequent PRs. For example, if a new physics suite is introduced, it may be possible to alter an existing test rather than creating an entirely new test. Code developers introducing new capabilities should work with code managers to provide the proper configuration files, data, and other information necessary to create new tests for these capabilities.
+Automated Testing on Jenkins
+-------------------------------
 
+`Jenkins <https://www.jenkins.io/>`__ is an "open source automation server" that allows users to automate code testing. In the SRW App, developers with write, maintain, or admin `roles <https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization>`__ on the SRW App repository can add labels to their PR that automatically initiate particular test suites. 
 
+The following automated testing labels are available (or will be soon) for the SRW App:
+   * ``run_ci`` 
+   * *Coming Soon:* ``run_we2e_comprehensive_tests``
+   * *Coming Soon:* ``run_we2e_fundamental_tests``
 
+Once a testing label is added to the PR and the tests are run, the results of the tests can be viewed by anyone on GitHub. Users must scroll down to the bottom of the PR, where PR approvals, checks, and conflicts are listed. Under checks, GitHub will list which checks have passed and which have failed. Users can click on "Details" beside each check to see the Jenkins log files (see :numref:`Figure %s <JenkinsCheck>`). This will take users to the Jenkins page with information on their PR's tests.
 
+.. _JenkinsCheck:
 
+.. figure:: _static/JenkinsCICD.png
+   :alt: Screenshot of the bottom of the PR where information on Jenkins tests is located.
 
+   *Sample of Jenkins Test Results*
 
+Once on the `Jenkins <https://jenkins-epic.woc.noaa.gov>`__ page specific to the PR check in question, users can view all of the testing output, including "artifacts" from the build. To do this, users must click on the arrow icon in the top right corner of the page. Then, in the left navigation menu, they can click on *S3 Artifacts* and download any files listed there for in-depth review.
 
 
 
diff --git a/docs/UsersGuide/source/Introduction.rst b/docs/UsersGuide/source/Introduction.rst
index 4c21dea4d5..fe351602a9 100644
--- a/docs/UsersGuide/source/Introduction.rst
+++ b/docs/UsersGuide/source/Introduction.rst
@@ -175,7 +175,7 @@ The SRW Application has a portable CMake-based build system that packages togeth
 
 The SRW Application allows for configuration of various elements of the workflow. For example, users can modify the parameters of the atmospheric model, such as start and end dates, duration, time step, and the physics suite used for the simulation. More information on how to do this is available in :numref:`Section %s <UserSpecificConfig>`.
 
-The SRW Application has been tested on a variety of platforms widely used by researchers, including NOAA High-Performance Computing (HPC) systems (e.g., Hera, Orion), cloud environments, and generic Linux and MacOS systems. Four `levels of support <https://github.com/ufs-community/ufs-srweather-app/wiki/Supported-Platforms-and-Compilers>`_ have been defined for the SRW Application. Preconfigured (Level 1) systems already have the required external libraries available in a central location (via :term:`HPC-Stack`). The SRW Application is expected to build and run out-of-the-box on these systems, and users can :ref:`download the SRW App code <DownloadSRWApp>` without first installing prerequisites. On other platforms (Levels 2-4), the SRW App can be :ref:`run within a container <QuickstartC>` that includes the HPC-Stack, or the required libraries will need to be installed as part of the :ref:`SRW Application build <BuildRunSRW>` process. Once these prerequisite libraries are installed, applications and models should build and run successfully. However, users may need to perform additional troubleshooting on Level 3 or 4 systems since little or no pre-release testing has been conducted on these systems. 
+The SRW Application has been tested on a variety of platforms widely used by researchers, including NOAA High-Performance Computing (HPC) systems (e.g., Hera, Orion), cloud environments, and generic Linux and MacOS systems. Four `levels of support <https://github.com/ufs-community/ufs-srweather-app/wiki/Supported-Platforms-and-Compilers>`__ have been defined for the SRW Application. Preconfigured (Level 1) systems already have the required external libraries available in a central location (via :term:`HPC-Stack`). The SRW Application is expected to build and run out-of-the-box on these systems, and users can :ref:`download the SRW App code <DownloadSRWApp>` without first installing prerequisites. On other platforms (Levels 2-4), the SRW App can be :ref:`run within a container <QuickstartC>` that includes the HPC-Stack, or the required libraries will need to be installed as part of the :ref:`SRW Application build <BuildRunSRW>` process. Once these prerequisite libraries are installed, applications and models should build and run successfully. However, users may need to perform additional troubleshooting on Level 3 or 4 systems since little or no pre-release testing has been conducted on these systems. 
 
 
 
@@ -239,17 +239,14 @@ The ``ufs-srweather-app`` :term:`umbrella repository` structure is determined by
    ├── manage_externals
    ├── modulefiles
    ├── regional_workflow
-   │     ├── docs
-   │     │     └── UsersGuide
    │     ├── (fix)
    │     ├── jobs
    │     ├── modulefiles
    │     ├── scripts
    │     ├── tests
-   │     │     └── baseline_configs
    │     └── ush
+   │          ├── machine
    │          ├── Python
-   │          ├── rocoto
    │          ├── templates
    │          └── wrappers
    ├── (share)
diff --git a/docs/UsersGuide/source/_static/JenkinsCICD.png b/docs/UsersGuide/source/_static/JenkinsCICD.png
new file mode 100644
index 0000000000..48c30bde1a
Binary files /dev/null and b/docs/UsersGuide/source/_static/JenkinsCICD.png differ
diff --git a/docs/UsersGuide/source/_static/theme_overrides.css b/docs/UsersGuide/source/_static/theme_overrides.css
index c38958b095..deb45e1974 100644
--- a/docs/UsersGuide/source/_static/theme_overrides.css
+++ b/docs/UsersGuide/source/_static/theme_overrides.css
@@ -6,6 +6,10 @@
          this as on RTD they are loaded after this stylesheet */
       white-space: normal !important;
    }
+   
+   .wy-nav-content {
+      max-width: 100% !important;
+   }
 
    /* .wy-table-responsive { */
    /*   overflow: visible !important; */