diff --git a/.spelling b/.spelling
index 7c7eb9881d6c..56808b006eee 100644
--- a/.spelling
+++ b/.spelling
@@ -129,6 +129,7 @@ args
 async
 auth
 backend
+backported
 boolean
 booleans
 buildkit
diff --git a/docs/releases.md b/docs/releases.md
index a84cee499d4f..9fa01789c146 100644
--- a/docs/releases.md
+++ b/docs/releases.md
@@ -1,26 +1,24 @@
 # Releases
 
-You can find the most recent version under [Github release](https://github.com/argoproj/argo-workflows/releases).
+You can find the most recent version in the [GitHub Releases](https://github.com/argoproj/argo-workflows/releases).
 
 ## Versioning
 
-Versions are expressed as `x.y.z`, where `x` is the major version, `y` is the minor version, and `z` is the patch version,
-following Semantic Versioning terminology.
+Versions are expressed as `x.y.z`, where `x` is the major version, `y` is the minor version, and `z` is the patch version, following Semantic Versioning terminology.
 
-Argo Workflows does not use Semantic Versioning. Minor versions may contain breaking changes. Patch versions only
-contain bug fixes and minor features.
+Argo Workflows does _not_ use Semantic Versioning.
+Minor versions may contain breaking changes.
+Patch versions only contain bug fixes and minor features.
 
 For **stable**, use the latest patch version.
 
-⚠️ Read the [upgrading guide](upgrading.md) to find out about breaking changes before any upgrade.
-
 ## Supported Versions
 
 We maintain release branches for the most recent two minor releases.
 
-Fixes may be back-ported to release branches, depending on severity, risk, and, feasibility.
+Fixes may be backported to release branches, depending on severity, risk, and feasibility.
 
-Breaking changes will be documented in [upgrading guide](upgrading.md).
+Breaking changes will be documented in the [upgrading guide](upgrading.md).
 
 ## Supported Version Skew
 
@@ -29,15 +27,16 @@ Both the `argo-server` and `argocli` should be the same version as the controlle
 ## Release Cycle
 
 New minor versions are released roughly every 6 months.
+Release Candidates (RCs) for major and minor versions are available roughly 4-6 weeks before General Availability (GA).
 
-Release candidates (RCs) for major and minor releases are typically available for 4-6 weeks before the release becomes generally available (GA). Features may be shipped in subsequent release candidates.
-
-When features are shipped in a new release candidate, the most recent release candidate will be available for at least 2 weeks to ensure it is tested sufficiently before it is pushed to GA. If bugs are found with a feature and are not resolved within the 2 week period, the features will be rolled back so as to be saved for the next major/minor release timeline, and a new release candidate will be cut for testing before pushing to GA.
+Features may be added in subsequent RCs.
+If they are, the RC will be available for at least 2 weeks to ensure sufficient testing before GA.
+If bugs are found with a feature and not resolved within the 2 week period, it will be rolled back and a new RC will be released before GA.
 
 Otherwise, we typically release every two weeks:
 
 * Patch fixes for the current stable version.
-* The next release candidate, if we are currently in a release-cycle.
+* The next RC, if we are currently in a release cycle.
 
 ## Kubernetes Compatibility Matrix