Update release and stable process based on recent events

docs/Contributing/release.rst

@@ -44,10 +44,10 @@ These are the general steps to prepare and finalize a release:
    series, there are some file updates needed:
 
    * :file:`.github/workflows/release.yaml` --- In the ``snapcraft`` section, change the ``release`` flag:
-     ``edge`` for Dev or Alpha, ``beta`` for Beta, ``candidate`` for the RC's, and ``stable`` for Stable.
+     ``edge`` for Dev or Alpha, ``beta`` for Beta, ``candidate`` for the RCs, and ``stable`` for Stable.
 
    * :file:`dist/*.metainfo.xml.in` --- At the bottom in the ``releases`` section, change the ``type`` value.
-     Use ``development`` for Dev, Alpha and Beta, ``candidate`` for the RC's, and ``stable`` for Stable.
+     Use ``development`` for Dev, Alpha and Beta, ``candidate`` for the RCs, and ``stable`` for Stable.
 
 #. When it is time, the release manager will finalize the release notes and ask for an editorial review in the
    ``#releases-project`` channel. Updates are made as per review.
@@ -64,7 +64,7 @@ These are the general steps to prepare and finalize a release:
 
    #. From the same page, create a new ``stable`` branch from ``master``.
 
-   #. Create a new ``stable`` branch protection setting.
+   #. Restore the ``stable`` branch protection setting.
 
    #. Update :file:`cmake/AutoRevision.txt` with the hash of the last commit in ``master`` and set a
       development version (``v[major version].[minor version]-dev.0``). Open a PR for this change to
@@ -76,14 +76,14 @@ These are the general steps to prepare and finalize a release:
 
 #. The release manager will add a tag to the release notes page and then click :guilabel:`Publish Release`.
    The format of the tag is ``v[major version].[minor version]-[release name].[number]``. For example:
-   ``v3.0-stable.5`` or ``v3.1-rc.1``. :strong:`The format is very important` to the build configuration
+   ``v3.0-patch.5`` or ``v3.1-rc.1``. :strong:`The format is very important` to the build configuration
    process.
 
 #. After a few minutes the continuous integration (CI) will open a PR titled
    ``Release Update of AutoRevision.txt``. The release manager will open the PR, click on the
    :guilabel:`Close pull request` button, and then click :guilabel:`Open pull request` button. This is a
    necessary step to handle a GitHub security feature. GitHub requires a human to be involved to merge CI
-   created PR's.
+   created PRs.
 
 #. While inside the ``Release Update of AutoRevision.txt`` PR, the release manager will enable an automatic
    rebase and merge.

docs/Contributing/stable-branch.rst

@@ -16,23 +16,23 @@ occasions where we are introducing major breaking changes that take time to reso
 back-port a commit (a single patch) or a Pull Request (a collection of commits) over to the ``stable`` branch.
 
 The ``stable`` branch is created when preparing for the first Release Candidate towards a stable release, see
-:doc:`release`.
-This page documents the rules and procedures for maintaining the ``stable`` branch.
+:doc:`release`. This page documents the rules and procedures for maintaining the ``stable`` branch.
 
 Requirements for a Back-Port
 ============================
 
 Only specific categories of commits will be approved for a back-port from ``master`` to ``stable``. They are:
 
-* :strong:`Bug Fixes` -- Not 100% of bug fixes should be back-ported, but certainly most should be considered.
-  `Breaking` bugs that are found and patched should always be back-ported.
-* :strong:`Documentation` -- We can support a ``latest`` and ``stable`` version in our documentation system.
+* :strong:`Bug Fixes` --- Not 100% of bug fixes should be back-ported, but certainly most should be considered.
+  *Breaking* bugs that are found and patched should always be back-ported.
+
+* :strong:`Documentation` --- We can support a ``latest`` and ``stable`` version in our documentation system.
   If there are issues found in our documentation that explicitly targets ``stable``, then we should back-port
   or author a Pull Request with a target of ``stable``.
 
 :strong:`Things we will not back-port`
 
-* :strong:`New Features or general improvements` -- This is what ``master`` branch is for.
+* :strong:`New Features or general improvements` --- This is what ``master`` branch is for.
 
 As we often do, we will allow common sense to dictate any deviations from these rules. However, it should be
 generally understood that there should be a careful consideration of what to back-port from ``master`` to
@@ -46,7 +46,9 @@ the primary comment that the PR is a back-port candidate. If the whole PR is not
 commit within the PR is, then this distinction should be highlighted as part of the comment. The full Commit
 ID is the definitive reference point to reduce ambiguity.
 
-As is customary, all PRs should target the ``master`` branch.
+As is customary, all PRs should target the ``master`` branch by default. If needed, contributors may also
+submit PRs that target the ``stable`` branch. Notes in the description should be clear as to why the PR is
+targeting the nom-development branch.
 
 Who Approves a Back-Port Request?
 =================================
@@ -59,6 +61,10 @@ of patches that need to be back-ported.
 The back-port project is here: https://github.com/orgs/longturn/projects/3. You can find it by going to the
 main Longturn GitHub repository page and click on the projects tab.
 
+.. note::
+  The back-port project is a protected project in the GitHub repository. If you do not have access, an access
+  request can be made in the ``LT.DEV`` section on our Discord server.
+
 As part of the review process, simply tag the PR to the project and add a ``back-port`` label to aid tracking.
 Once the PR has been merged into ``master``, go get the commit ID(s) and add those to the appropriate column
 in the project. Multiple Commit IDs should be separated by a space.
@@ -76,3 +82,8 @@ Follow these steps:
 #. Run ``git cherry-pick -x $(cat commits.txt)``
 #. Push ``stable`` to upstream: ``git push upstream``
 #. Update the project sheet to denote which commits were back-ported.
+
+.. note::
+  The only time that we allow a direct push to ``stable`` branch is via the cherry pick approach described
+  above. All other commits to ``stable`` should either follow the existing back-port process, or via a PR that
+  targets ``stable`` directly so the standard review process is followed.