docs: release process - add follow up section

.github/config/wordlist.txt

@@ -215,6 +215,7 @@ packageversion
 parameterization
 pendingdeprecationwarning
 pflag
+pkgs
 podinfo
 podman
 pre

RELEASE_PROCESS.md

@@ -18,8 +18,8 @@ created.
 The release branches are initially created from the `main` branch via the GitHub
 action [`Release Branch Creation`](./.github/workflows/release-branch.yaml).
 
-A release is generated by calling a specific [
-`release`](./.github/workflows/release.yaml) GitHub Action. It is
+A release is generated by calling a specific
+[`release`](./.github/workflows/release.yaml) GitHub Action. It is
 executed on the branch which should be released - regardless whether it is a
 patch or a minor release.
 
@@ -63,11 +63,11 @@ 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).
+Every minor release starts with the creation of a release branch through
+[`Release Branch Creation`](./.github/workflows/release-branch.yaml).
 
-The version / minor of the release is based on the content of the file [
-`VERSION`](./VERSION) which
+The version / minor of the release is based on the content of the file
+[`VERSION`](./VERSION) which
 is updated automatically said `release` action. During development, the
 content of this file is the complete release name of the release currently under
 development and the suffix `-dev` (e.g. `0.1.0-dev`). The content of this file
@@ -93,8 +93,8 @@ This means that:
   the release manager
 - Any bug fix that is not deemed critical must be approved by the release
   manager
-- Any bug fix must first be merged to main and then [
-  `cherry-picked`](https://git-scm.com/docs/git-cherry-pick) to the release
+- Any bug fix must first be merged to main and then
+  [`cherry-picked`](https://git-scm.com/docs/git-cherry-pick) to the release
   branch.
 
 At this point in time, any release targeted on this branch will have this minor
@@ -143,12 +143,12 @@ 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,
 with the difference that the `-rc.<rc-number>` suffix is removed.
 
-After the build, instead of finishing, the [
-`release`](./.github/workflows/release.yaml) GitHub Action will also publish the
+After the build, instead of finishing, the
+[`release`](./.github/workflows/release.yaml) GitHub Action will also publish 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)
+This publishing to package registries (such as brew) is delegated to
+[`publish-to-other-than-github`](./.github/workflows/publish-to-other-than-github.yaml)
 
 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
@@ -244,3 +244,27 @@ branches were created on demand.
 This model has now largely been replaced by the model we see in
 this document. However you might still encounter leftovers form the old model
 and you are encouraged to create issues regarding inconsistencies.
+
+## Follow up actions
+
+Review and merge open pull requests.
+
+### ocm-website
+
+[Update the website](https://github.com/open-component-model/ocm-website/pulls).
+
+### homebrew-tap
+
+[Update brew tap](https://github.com/open-component-model/homebrew-tap/pulls).
+
+### winget-pkgs
+
+[Check winget-pkgs PRs for: `New version: Open-Component-Model.ocm-cli`](https://github.com/microsoft/winget-pkgs/pulls?q=is%3Apr+is%3Aopen+New+version%3A+Open-Component-Model.ocm-cli).
+
+### chocolatey
+
+[Check the `Packages in Moderation`](https://community.chocolatey.org/profiles/ocm.software#profile-moderation).
+
+### piper-ocm-cli
+
+[Update piper-ocm-cli](https://github.tools.sap/open-component-model/piper-ocm-cli/pulls).