final nits

Signed-off-by: mbianchidev <mbianchidev@github.com>

Author: mbianchidev

.github/ISSUE_TEMPLATE/cut-release.md

@@ -88,8 +88,7 @@ Help? Ring @release-managers on slack!
 - [ ] Update [`schedule.yaml` file](https://github.com/kubernetes/website/blob/main/data/releases/schedule.yaml) with the latest release using [`schedule-builder`](https://github.com/kubernetes/release/tree/master/cmd/schedule-builder) (_patch releases only_) <!-- Paste Pull Request URL here -->
 - [ ] Collect metrics and add them to the `Release steps` table below through `krel history --branch release-1.xx --date-from yyyy-mm-dd` (current date)
 <!-- ONLY FOR RC.0 RELEASES - [ ] Post-release branch creation tasks -->
-<!-- ONLY FOR RC.1 RELEASES - [ ] Ensure that the new OBS project is set -->
-<!-- ONLY FOR STABLE RELEASES - [ ] Code Thaw PR merged and mention @release-managers nudging them to perform the propedeutic tasks for the next alpha (e.g. setting up the new OBS project) -->
+<!-- ONLY FOR .0 RELEASE - [ ] Code Thaw PR merged and OBS project created for the new minor release -->
 
 ## Release Tools Version
 

.github/ISSUE_TEMPLATE/post-release-branch-creation.md

@@ -18,8 +18,7 @@ Help? Ring @release-managers on slack!
 -->
 
 - [ ] Create a thread in #release-management: <!-- Paste link to Slack thread -->
-- [ ] Promote the subsequent minor release alpha.0 image
-- [ ] (optional) Remove jobs for EOL versions, **only** if agreed upon with Release Managers and totally ok to delegate this to @release-managers
+- [ ] (optional) Remove jobs for EOL versions, **only** if agreed upon with Release Managers
 <!--
 Branch Managers might not have a context on if it is "safe" to remove the EOL jobs. We try to be firm with the deadlines and stop cutting patches as soon as we reach the EOL date, but e.g. there might be a new patch needed because of some important security fix, in which case only Release Managers will know about that.
 

release-engineering/handbooks/post-release-branch-creation.md

@@ -3,7 +3,6 @@
 <!-- toc -->
 - [Post release branch creation](#post-release-branch-creation)
   - [Checklist](#checklist)
-    - [Promote the subsequent minor release alpha.0 image](#promote-the-subsequent-minor-release-alpha0-image)
     - [Remove EOL version jobs from test-infra (optional)](#remove-eol-version-jobs-from-test-infra-optional)
     - [Update milestone applier rules and check milestone requirements](#update-milestone-applier-rules-and-check-milestone-requirements)
     - [Update Kubekins-e2e v2 variants](#update-kubekins-e2e-v2-variants)
@@ -32,12 +31,6 @@ It is essential to follow these steps to maintain the integrity of the release p
 
 Open a new issue using [this template](https://github.com/kubernetes/sig-release/issues/new?template=post-release-branch-creation.md).
 
-### Promote the subsequent minor release alpha.0 image
-
-Recall that an alpha.0 of the next minor release is created during the rc.0 cut?
-
-To assist downstream consumers of Kubernetes, this new alpha is automatically cut to bring our next release tag to the tip of `master`, what we need to do manually is [promoting](k8s-release-cut.md#7-image-promotion) the alpha.0 image, after the rc.0 image ProwJob is green.
-
 ### Remove EOL version jobs from test-infra (optional)
 
 Consider removing jobs for versions that are going EOL. This is sometimes done before adding new jobs to avoid overwhelming the Prow cluster.