diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md
index ace177a80..c7098631a 100644
--- a/RELEASE_PROCESS.md
+++ b/RELEASE_PROCESS.md
@@ -34,13 +34,19 @@ Minor releases are done every sprint, i.e. every two weeks. To be even more prec
 technically speaking, two releases are produced every sprint:
 
 * Release Candidate for the current version in main
-* Promotion of the previous sprint's candidate to an official minor version
+* Promotion of the previous sprint's candidate to an official minor version, which means there
+is a grace period of one sprint.
 
-At the end of each sprint (usually on Friday) a new release ungineer is selected,
+At the end of each sprint (usually on Friday) a new release engineer is selected,
 who has to produce the releases.
 
 Patch releases are produced on demand, if a fix for a hefty bug must be released quickly,
-and it is approved by the responsible engineer and release manager.
+and it is approved by the responsible engineer and release manager. For example, a patch
+is recommended for any change that is breaking backwards-compatibility or has high/critical
+security relevance.
+
+In very rare cases it might be required to build a version outside the regular release
+schedule, e.g. a special beta release.
 
 ### Release Manager
 
@@ -49,11 +55,12 @@ is to deal with the release process. Responsibilities of the release manager inc
 
 * Agreeing with the team, if a new release has to be produced. Sometimes, e.g. if there were
 no significant contributions, or the branch is not ready, the release can be skipped
-* Release branch cut-off
-* Preparing a minor release candidate
-* Creating a minor release
-* Creating patch releases
-* Approving merges into release branches and making sure they were cherry-picked from main
+* [Release branch cut-off](#the-release-branch-creation--cutoff)
+* [Preparing a minor release candidate](#preparing-a-minor-release-candidate)
+* [Creating a minor release](#creating-a-minor-release)
+* [Creating patch releases](#creating-a-patch-release)
+* Approving merges into release branches and making sure the changes were cherry-picked from main
+and fulfill "feature freeze" and "no breaking changes" requirements
 * Improving release process documentation (this page)
 
 ## Release Workflow
@@ -92,7 +99,8 @@ gitGraph TB:
 ### The Release Branch Creation / Cutoff
 
 Every minor release starts with the creation of a release branch through
-[`Release Branch Creation`](./.github/workflows/release-branch.yaml).
+[`Release Branch Creation`](./.github/workflows/release-branch.yaml), by
+executing the [Release Branch Cutoff action](https://github.com/open-component-model/ocm/actions/workflows/release-branch.yaml).
 
 The version / minor of the release is based on the content of the file
 [`VERSION`](./VERSION) which
@@ -131,8 +139,8 @@ version as a base.
 ### Preparing a Minor release candidate
 
 After the cut-off, the release manager will usually prepare a release candidate.
-This is done by creating a pre-release on the release branch, that goes along
-with a qualifying suffix.
+This is done by running [Release workflow](https://github.com/open-component-model/ocm/actions/workflows/release.yaml)
+on the release branch, while specifying a qualifying suffix.
 
 Currently we only use one form of suffixed, pre-release, the
 `Release Candidate`: Any Release Candidate
@@ -160,12 +168,12 @@ for details.
 ### Creating a Minor release
 
 Once a release candidate is seen as sufficiently tested, the release manager can
-promote the release candidate to a full release.
+promote the release candidate to a full release, by running
+[Release workflow](https://github.com/open-component-model/ocm/actions/workflows/release.yaml)
+on the release branch, without specifying a qualifying suffix.
 
-By default one should always create a draft release first (as a Release
-Candidate),
-open it up for testing (by communicating the new release candidate as available
-to stakeholders),
+By default one should always create [release candidate](#preparing-a-minor-release-candidate)
+first (automated announcement is posted to an internal Slack channel, so the stakeholders can start testing),
 and after a grace period, promote the draft release to a full release.
 
 This promotion is currently effectively a full rebuild from the release branch,
@@ -176,7 +184,8 @@ After the build, instead of finishing, the
 release.
 
 This publishing to package registries (such as brew) is delegated to
-[`publish-to-other-than-github`](./.github/workflows/publish-to-other-than-github.yaml)
+[`publish-to-other-than-github`](./.github/workflows/publish-to-other-than-github.yaml),
+which runs automatically as part of the release workflow.
 
 After the official release on a release branch was successful, the version is considered `burned`.
 This means that, even if bugs are found for that release in the future, a
@@ -237,6 +246,9 @@ necessary:
 
 ### How Release Notes are managed
 
+The release notes are auto-generated by the release action,
+thus don't have to be explicitly handled by the release manager.
+
 For every release branch there is a Github Action
 called [Release Drafter](./.github/workflows/release-drafter.yaml).
 This workflow interprets the Pull Requests merged against main and the release