diff --git a/cumulus/.github/ISSUE_TEMPLATE/release-client.md b/cumulus/.github/ISSUE_TEMPLATE/release-client.md
new file mode 100644
index 0000000000000000000000000000000000000000..016f0a4c0b15641cf54266be1f7ce95b490f0f9b
--- /dev/null
+++ b/cumulus/.github/ISSUE_TEMPLATE/release-client.md
@@ -0,0 +1,20 @@
+---
+name: Release Checklist for Client - issue template
+about: Release Checklist for Client
+title: Release Checklist - Client {{ env.VERSION }}
+---
+
+# Release Checklist - Client
+
+### Client Release
+
+- [ ] build a new `polkadot-parachain` binary and publish it to S3
+- [ ] new `polkadot-parachain` version has [run on the network](../../docs/release.md#burnin)
+    without issue for at least 12h
+- [ ] a draft release has been created in the [Github Releases page](https://github.com/paritytech/cumulus/releases) with the relevant release-notes
+- [ ] the [build artifacts](../../docs/release.md#build-artifacts) have been added to the
+    draft-release.
+
+---
+
+Read more about the [release documentation](../../docs/release.md).
diff --git a/cumulus/.github/ISSUE_TEMPLATE/release-runtime.md b/cumulus/.github/ISSUE_TEMPLATE/release-runtime.md
new file mode 100644
index 0000000000000000000000000000000000000000..25157a82806edfac60a564a5e2671f90344764a3
--- /dev/null
+++ b/cumulus/.github/ISSUE_TEMPLATE/release-runtime.md
@@ -0,0 +1,46 @@
+---
+name: Release issue template
+about: Tracking issue for new releases
+title: Cumulus {{ env.VERSION }} Release checklist
+---
+
+# Release Checklist - Runtimes
+
+## Runtimes Release
+
+### Codebase
+These checks should be performed on the codebase.
+
+- [ ] the [`spec_version`](../../docs/release.md#spec-version) has been incremented since the
+    last release for any native runtimes from any existing use on public (non-private/test) networks
+- [ ] previously [completed migrations](../../docs/release.md#old-migrations-removed) are
+    removed for any public (non-private/test) networks
+- [ ] No migrations added in the last release that would need to be removed
+- [ ] pallet and [extrinsic ordering](../../docs/release.md#extrinsic-ordering) as well as `SignedExtension`s have stayed
+    the same. Bump `transaction_version` otherwise
+- [ ] the [benchmarks](../../docs/release.md#benchmarks) ran
+- [ ] the weights have been updated for any modified runtime logic
+- [ ] the various pieces of XCM config are sane
+
+### On the release branch
+
+The following checks can be performed after we have forked off to the release-
+candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
+
+- [ ] Verify [new migrations](../../docs/release.md#new-migrations) complete successfully, and the
+    runtime state is correctly updated for any public (non-private/test)
+    networks
+- [ ] Run integration tests
+- [ ] Push runtime upgrade to Westmint and verify network stability
+
+
+### Github
+
+- [ ] Check that a draft release has been created at the [Github Releases page](https://github.com/paritytech/cumulus/releases) with relevant [release
+    notes](../../docs/release.md#release-notes)
+- [ ] Check that [build artifacts](../../docs/release.md#build-artifacts) have been added to the
+    draft-release.
+
+---
+
+Read more about the [release documentation](../../docs/release.md).
diff --git a/cumulus/.github/ISSUE_TEMPLATE/release.md b/cumulus/.github/ISSUE_TEMPLATE/release.md
deleted file mode 100644
index 702fec940ced3d2cfd7a1f05104af4723f7fe74c..0000000000000000000000000000000000000000
--- a/cumulus/.github/ISSUE_TEMPLATE/release.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: Release issue template
-about: Tracking issue for new releases
-title: Cumulus {{ env.VERSION }} Release checklist
----
-# Release Checklist
-
-### Runtime Releases
-
-These checks should be performed on the codebase.
-
-- [ ] Verify [`spec_version`](#spec-version) has been incremented since the
-    last release for any native runtimes from any existing use on public
-    (non-private/test) networks.
-- [ ] Verify previously [completed migrations](#old-migrations-removed) are
-    removed for any public (non-private/test) networks.
-  - No migrations added in the last release that would need to be removed.
-- [ ] Verify pallet and [extrinsic ordering](#extrinsic-ordering) as well as `SignedExtension`s have stayed
-    the same. Bump `transaction_version` if not.
-- [ ] Verify new extrinsics have been correctly whitelisted/blacklisted for
-    [proxy filters](#proxy-filtering).
-  - No new extrinsics.
-- [ ] Verify [benchmarks](#benchmarks) have been updated for any modified
-    runtime logic.
-  - [ ] Verify the weights are up-to-date.
-- [ ] Verify that the various pieces of XCM config are sane.
-
-The following checks can be performed after we have forked off to the release-
-candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
-
-- [ ] Verify [new migrations](#new-migrations) complete successfully, and the
-    runtime state is correctly updated for any public (non-private/test)
-    networks.
-- [ ] Run integration tests.
-  - [ ] Teleport Relay -> Statemin* and back.
-  - [ ] Create asset (if applicable), mint and transfer
-- [ ] Push runtime upgrade to Westmint and verify network stability.
-
-
-### All Releases
-
-- [ ] Check that the new polkadot-parachain versions have [run on the network](#burn-in)
-    without issue.
-- [ ] Check that a draft release has been created at
-    https://github.com/paritytech/cumulus/releases with relevant [release
-    notes](#release-notes).
-- [ ] Check that [build artifacts](#build-artifacts) have been added to the
-    draft-release.
-
----
-
-## Notes
-
-### Burn In
-
-Ensure that Parity DevOps has run the new release on Westmint and Statemine collators for 12h prior to publishing the release.
-
-### Build Artifacts
-
-Add any necessary assets to the release. They should include:
-
-- Linux binary
-- GPG signature of the Linux binary
-- SHA256 of binary
-- Source code
-- Wasm binaries of any runtimes
-
-### Release notes
-
-The release notes should list:
-
-- The priority of the release (i.e., how quickly users should upgrade) - this is
-    based on the max priority of any *client* changes.
-- Which native runtimes and their versions are included
-- The proposal hashes of the runtimes as built with
-    [srtool](https://github.com/paritytech/srtool)
-- Any changes in this release that are still awaiting audit
-
-The release notes may also list:
-
-- Free text at the beginning of the notes mentioning anything important
-    regarding this release
-- Notable changes separated into sections.
-
-### Spec Version
-
-A runtime upgrade must bump the spec number. This may follow a pattern with the
-client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
-runtime is not v11).
-
-### Runtime version bump between RCs
-
-The clients need to be aware of runtime changes. However, we do not want to bump the
-`spec_version` for every single release candidate. Instead, we can bump the `impl` field of the version
-to signal the change to the client.
-
-### Old Migrations Removed
-
-Previous `on_runtime_upgrade` functions from old upgrades should be removed.
-
-### New Migrations
-
-Ensure that any migrations that are required due to storage or logic changes
-are included in the `on_runtime_upgrade` function of the appropriate pallets.
-
-### Extrinsic Ordering & Storage
-
-Offline signing libraries depend on a consistent ordering of call indices and
-functions. Compare the metadata of the current and new runtimes and ensure that
-the `module index, call index` tuples map to the same set of functions. It also checks if there have been any changes in `storage`. In case of a breaking change, increase `transaction_version`.
-
-To verify the order has not changed, manually start the following [Github Action](https://github.com/paritytech/cumulus/actions/workflows/extrinsic-ordering-check-from-bin.yml). It takes around a minute to run and will produce the report as artifact you need to manually check.
-
-To run it, in the _Run Workflow_ dropdown:
-1. **Use workflow from**: to ignore, leave `master` as default
-2. **The WebSocket url of the reference node**:
-    - Statemine: `wss://kusama-statemine-rpc.paritytech.net`
-    - Westmint: `wss://westmint-rpc.polkadot.io`
-3. **A url to a Linux binary for the node containing the runtime to test**: Paste the URL of the latest release-candidate binary from the draft-release on Github. The binary has to previously be uploaded to S3 (Github url link to the binary is constantly changing)
-    - https://releases.parity.io/cumulus/statemine-v6.0.0-rc1/polkadot-collator
-4. **The name of the chain under test. Usually, you would pass a local chain**:
-    - Statemine: `statemine-local`
-    - Westmint: `westmint-local`
-5. Click **Run workflow**
-
-When the workflow is done, click on it and download the zip artifact, inside you'll find an `output.txt` file. The things to look for in the output are lines like:
-
-- `[Identity] idx 28 -> 25 (calls 15)` - indicates the index for Identity has changed
-- `[+] Society, Recovery` - indicates the new version includes 2 additional modules/pallets.
-- If no indices have changed, every modules line should look something like `[Identity] idx 25 (calls 15)`
-
-**Note**: Adding new functions to the runtime does not constitute a breaking change
-as long as the indexes did not change.
-
-**Note**: Extrinsic function signatures changes (adding/removing & ordering arguments) are not caught by the job, so those changes should be reviewed "manually"
-
-### Proxy Filtering
-
-The runtime contains proxy filters that map proxy types to allowable calls. If
-the new runtime contains any new calls, verify that the proxy filters are up to
-date to include them.
-
-### Benchmarks
-
-Until #631 is done, running the benchmarks is a manual process:
-1. Connect to the bechmarking machine
-2. Make sure no one else is using the machine with `htop check`
-3. Pull in the branch of Cumulus that has the version of Statemine you want to release
-4. Recompile `cargo build --profile production --locked --features runtime-benchmarks`
-5. From the root directory run `nohup ./scripts/benchmarks.sh &` (it will take quite a few hours)
-6. Checkout in your local machine to the branch of cumulus that has the version of Statemine you want to release
-7. `scp` from the host to your local machine the weights for Statemine, Westmint and Statemint you'll find in:
-   - `/parachains/runtimes/assets/statemine/src/weights`
-   - `/parachains/runtimes/assets/statemint/src/weights`
-   - `/parachains/runtimes/assets/westmint/src/weights`
-8. Commit the changes in your local and create a PR
diff --git a/cumulus/.github/workflows/release-01_rc-automation.yml b/cumulus/.github/workflows/release-01_rc-automation.yml
index 439e4bd3fb9519c334ee0a2acec9e2d9d663e868..3d6b607e1eddce8360d5652f9735fc56b9f8cc00 100644
--- a/cumulus/.github/workflows/release-01_rc-automation.yml
+++ b/cumulus/.github/workflows/release-01_rc-automation.yml
@@ -1,4 +1,4 @@
-name: Release-candidate automation
+name: RC automation
 on:
   push:
     branches:
@@ -34,6 +34,7 @@ jobs:
             echo "::set-output name=new_tag::$version-rc1"
             echo "::set-output name=first_rc::true"
           fi
+
       - name: Apply new tag
         uses: tvdias/github-tagger@v0.0.2
         with:
@@ -42,22 +43,38 @@ jobs:
           # RELEASE_BRANCH_TOKEN requires public_repo OAuth scope
           repo-token: "${{ secrets.RELEASE_BRANCH_TOKEN }}"
           tag: ${{ steps.compute_tag.outputs.new_tag }}
-      - id: create-issue
-        uses: JasonEtco/create-an-issue@v2
+
+      - id: create-issue-checklist-client
+        uses: JasonEtco/create-an-issue@v9e6213aec58987fa7d2f4deb8b256b99e63107a2 # v2.6.0
+        # Only create the issue if it's the first release candidate
+        if: steps.compute_tag.outputs.first_rc == 'true'
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          VERSION: ${{ steps.compute_tag.outputs.version }}
+        with:
+          assignees: release-engineering
+          filename: .github/ISSUE_TEMPLATE/release-client.md
+
+      - id: create-issue-checklist-runtime
+        uses: JasonEtco/create-an-issue@v9e6213aec58987fa7d2f4deb8b256b99e63107a2 # v2.6.0
         # Only create the issue if it's the first release candidate
         if: steps.compute_tag.outputs.first_rc == 'true'
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           VERSION: ${{ steps.compute_tag.outputs.version }}
         with:
-          filename: .github/ISSUE_TEMPLATE/release.md
+          assignees: release-engineering
+          filename: .github/ISSUE_TEMPLATE/release-runtime.md
+
       - name: Send Matrix message
         uses: s3krit/matrix-message-action@v0.0.3
-        if: steps.create-issue.outputs.url != ''
+        if: steps.create-issue-checklist-client.outputs.url != '' && steps.create-issue-checklist-runtime.outputs.url != ''
         with:
           room_id: ${{ secrets.INTERNAL_CUMULUS_MATRIX_ROOM_ID }}
           access_token: ${{ secrets.MATRIX_ACCESS_TOKEN }}
           server: "matrix.parity.io"
           message: |
-            Release process for Cumulus ${{ steps.compute_tag.outputs.version }} has been started.
-            Tracking issue: ${{ steps.create-issue.outputs.url }}"
+            The Release Process for Cumulus ${{ steps.compute_tag.outputs.version }} has been started.
+            Tracking issues:
+              - client: ${{ steps.create-issue-checklist-client.outputs.url }}"
+              - runtime: ${{ steps.create-issue-checklist-runtime.outputs.url }}"
diff --git a/cumulus/docs/release.md b/cumulus/docs/release.md
new file mode 100644
index 0000000000000000000000000000000000000000..a5adc21b387cb1e18e238594ce7cdbb473738e94
--- /dev/null
+++ b/cumulus/docs/release.md
@@ -0,0 +1,109 @@
+# Releases
+
+## Versionning
+
+### Example #1
+
+```
+| Polkadot   | v  0. 9.22    |
+| Client     | v  0. 9.22 0  |
+| Runtime    | v     9 22 0  |  =>  9220
+| senmver    |    0. 9.22 0  |
+```
+
+### Example #2
+
+```
+| Polkadot   | v  0.10.42    |
+| Client     | v  0.10.42 0  |
+| Runtime    | v    10.42 0  |  => 10420
+| senmver    |    0.10.42 0  |
+```
+
+### Example #3
+
+```
+| Polkadot   | v  1. 2.18    |
+| Client     | v  1. 2.18 0  |
+| Runtime    | v  1  2 18 0  |  => 102180
+| senmver    |    1. 2.18 0  |
+```
+
+
+This document contains information related to the releasing process and describes a few of the steps and checks that are
+performed during the release process.
+
+## Client
+
+### <a name="burnin"></a>Burn In
+
+Ensure that Parity DevOps has run the new release on Westmint and Statemine collators for 12h prior to publishing the
+release.
+
+### Build Artifacts
+
+Add any necessary assets to the release. They should include:
+
+- Linux binaries
+    - GPG signature
+    - SHA256 checksum
+- WASM binaries of the runtimes
+- Source code
+
+
+## Runtimes
+
+### Spec Version
+
+A new runtime release must bump the `spec_version`. This may follow a pattern with the client release (e.g. runtime
+v9220 corresponds to v0.9.22).
+
+### Runtime version bump between RCs
+
+The clients need to be aware of runtime changes. However, we do not want to bump the `spec_version` for every single
+release candidate. Instead, we can bump the `impl` field of the version to signal the change to the client. This applies
+only to runtimes that have been deployed.
+
+### Old Migrations Removed
+
+Previous `on_runtime_upgrade` functions from old upgrades should be removed.
+
+### New Migrations
+
+Ensure that any migrations that are required due to storage or logic changes are included in the `on_runtime_upgrade`
+function of the appropriate pallets.
+
+### Extrinsic Ordering & Storage
+
+Offline signing libraries depend on a consistent API of call indices and functions. Nowadays, we are no longer using
+indices but the task of checking whether the API remains compatible remained and the name "Extrinsic Ordering" remained
+as well although we no longer check the ordering itself.
+
+Compare the metadata of the current and new runtimes and ensure that the `module index, call index` tuples map to the
+same set of functions. It also checks if there have been any changes in `storage`. In case of a breaking change,
+increase `transaction_version`.
+
+To verify that the API did not break, manually start the following [Github
+Action](https://github.com/paritytech/cumulus/actions/workflows/extrinsic-ordering-check-from-bin.yml). It takes around
+a minute to run and will produce the report as artifact you need to manually check.
+
+When the workflow is done, click on it and download the zip artifact, inside you'll find an `output.txt` file. The
+output should be appended as comment to the "Checklist issue".
+
+The things to look for in the output are lines like:
+
+- `[Identity] idx 28 -> 25 (calls 15)` - indicates the index for Identity has changed
+- `[+] Society, Recovery` - indicates the new version includes 2 additional modules/pallets
+- If no indices have changed, every modules line should look something like `[Identity] idx 25 (calls 15)`
+
+**Note**: Adding new functions to the runtime does not constitute a breaking change as long as the indexes did not
+change.
+
+**Note**: Extrinsic function signatures changes (adding/removing & ordering arguments) are not caught by the job, so
+those changes should be reviewed "manually"
+
+### Benchmarks
+
+The Benchmarks can now be started from the CI. First find the CI pipeline from
+[here](https://gitlab.parity.io/parity/mirrors/cumulus/-/pipelines?page=1&scope=all&ref=release-parachains-v9220) and
+pick the latest.