move schedule out of handbook, into v1.31 release

.github/ISSUE_TEMPLATE/cut-release.md

@@ -84,7 +84,7 @@ Help? Ring @release-managers on slack!
   - [ ] Release
 - [ ] Notify #release-management: <!-- Paste link to slack -->
 - [ ] Send notification: <!-- Paste link to kubernetes-dev email -->
-- [ ] Update [`schedule.yaml` file](https://github.com/kubernetes/website/blob/main/data/releases/schedule.yaml) with the latest release <!-- Paste Pull Request URL here -->
+- [ ] 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) <!-- Paste Pull Request URL here -->
 - [ ] Collect metrics and add them to the `Release steps` table below
 <!-- ONLY FOR RC.0 RELEASE - [ ] Finish post-release branch creation tasks -->
 

OWNERS_ALIASES

@@ -29,6 +29,7 @@ aliases:
     - justaugustus # subproject owner
     - katcosgrove # 1.30 Release Lead
     - leonardpahlke # subproject owner / 1.26 Release Team Lead
+    - neoaggelos # 1.31 Release Lead
     - Priyankasaggu11929 # subproject owner / Kubernetes 1.29 Release Lead
     - puerco # subproject owner
     - salaxander # subproject owner / 1.27 Release Team Lead
@@ -43,6 +44,7 @@ aliases:
     - gracenng # Kubernetes 1.28 Release Lead
     - katcosgrove # Kubernetes 1.30 Release Lead
     - leonardpahlke # Kubernetes 1.26 Release Lead
+    - neoaggelos # Kubernetes 1.31 Release Lead
     - Priyankasaggu11929 # Kubernetes 1.29 Release Lead
     - salaxander # Kubernetes 1.27 Release Lead
   release-signal-role:

release-engineering/README.md

@@ -25,7 +25,6 @@
 
 - [Slack](https://kubernetes.slack.com/messages/release-management)
 - [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-release)
-- [GitHub Project board with open issues and pull requests](https://github.com/orgs/kubernetes/projects/30)
 - [Meeting agenda and notes](https://bit.ly/k8s-releng-meeting)
 
 ### Slack
@@ -38,9 +37,9 @@
 
 We use the [kubernetes-sig-release@ mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-release). Feel free to use it if you have a topic or question that, due to its complexity or need for brainstorming discussion, would be difficult to resolve over Slack or GitHub.
 
-### GitHub Project Board
+### Roadmap and Vision
 
-Release Engineering's work involves several repositories in the project ecosystem, so we keep track of our backlog [here](https://github.com/orgs/kubernetes/projects/30). This is a great place to look if you're a newcomer looking to help out, as it includes unassigned, `help wanted` and `good first issue` cards. 
+Please see the SIG Release Roadmap and Vision document [here](https://github.com/kubernetes/sig-release/blob/master/roadmap.md). This is a great place to look if you're a newcomer looking to help out. 
 
 ### Meetings
 
@@ -114,8 +113,7 @@ We do not bypass the “at least one reviewer” rule, so please wait for a revi
 
 ### Tracking Progress
 
-- We use our [project board](https://github.com/orgs/kubernetes/projects/30) and try to review it during the Release Engineering meeting. 
-    - Note that project boards also exist for [SIG Release](https://github.com/orgs/kubernetes/projects/23) and the [Release Team](https://github.com/orgs/kubernetes/projects/29).
+- We use project boards linked in the [Roadmap and Vision document](https://github.com/kubernetes/sig-release/blob/master/roadmap.md) and try to review them during the Release Engineering meeting.
 - As of Autumn 2020 SIG Release is setting up an instance of Triage Party to accelerate and automate triaging issues.
 - We organize our work into sub-themes based on urgency and impact, and identify drivers of those topics.
 - We call out and celebrate achievements. Some suggested communication paths for amplifying:

release-engineering/role-handbooks/branch-manager.md

@@ -535,6 +535,12 @@ Proceed with the [alpha release steps](#alpha-releases).
 
 Example `1.18.0-alpha.1` release issue template: https://github.com/kubernetes/sig-release/issues/928
 
+#### Branching perf-tests
+
+Reach out to SIG Scalability to ensure a new branch is cut in [sigs.k8s.io/perf-tests](https://github.com/kubernetes/perf-tests/) repository. 
+
+In case the release branch is missing - we will end up with an issue we had for 1.30: https://github.com/kubernetes/kubernetes/issues/124119
+
 ## Branch Management
 
 This section discusses the methods in managing commits on the `release-x.y` branch.

release-engineering/versioning.md

@@ -12,7 +12,7 @@ Legend:
 
 ### Minor version scheme and timeline
 
-- X.Y.0-{alpha,beta}.W, W > 0 (Branch: master)
+- X.Y.0-{alpha,beta}.W, W >= 0 (Branch: master)
   - Alpha and beta releases are created roughly every two weeks directly from
     the master branch.
   - Depending on the release schedule progress, the release team decides when to

release-team/release-team-removal.md

@@ -22,7 +22,7 @@ Note that communications ahead of time to inform the leads or find alternative a
 ### Process
 It is important to be kind and patient while trying to resolve the situation.
 - Upon a pattern of inactivity, the Role Lead will notify the EA and have an initial discussion with the shadow about their performance.
-- If the shadow is still not contributing to the team, the EA and the Release Lead will remove the shadow from the team, and find a replacement if appropriate. The EA will be responsible for finding backfill.
+- If the shadow is still not contributing to the team, the Release Team Subproject Leads or the Release Lead will remove the shadow from the team, and find a replacement if appropriate. The EA will be responsible for finding backfill.
 
 ### Consequences
 - If the current release is the reason the shadow has Kubernetes membership, membership should be revoked
@@ -39,14 +39,14 @@ Reasons for removal could include but are not limited to:
 - Violation of [CNCF Code of Conduct](http://cncf.io/conduct/)
 
 ### Process
-- SIGs outside of SIG Release, shadows, leads, or contributors can express concern to the Release Lead or EA.
+- SIGs outside of SIG Release, shadows, leads, or contributors can express concern to the Release Team Subproject Leads, Release Lead, or EA
 - The Release Lead and the EA will have an initial discussion with the Role Lead
 - If the situation is not improved, the Release Lead and EA will have another discussion with the Role Lead and begin to look for a replacement
-- If deemed necessary by the Release Lead, EA and SIG Release chairs, the Role Lead will be replaced with an experienced shadow or someone who previously led the same role. EA will be responsible for finding backfill
+- If deemed necessary by the Release Lead, EA and Release Team Subproject Leads, the Role Lead will be replaced with an experienced shadow or someone who previously led the same role. EA will be responsible for finding backfill
 
 ### Consequences
 - Removal of name in release-team document
 - Role lead will need to shadow again and demonstrate sufficient responsibility, and leading ability, before holding another leadership position on the release team
 
 ## Appeal
-If the release team member disagrees with their removal decision. They can escalate to SIG-Release chairs by sending an email to sig-release-leads@kubernetes.io.
+If the release team member disagrees with their removal decision. They can escalate to SIG Release chairs by sending an email to sig-release-leads@kubernetes.io.

release-team/role-handbooks/communications/README.md

@@ -53,11 +53,20 @@ There is a channel on the Kubernetes Slack workspace, `#release-comms`, which is
 ## Release deliverables
 
 Throughout the release cycle, the main Communications deliverables include:
-* **Authoring the Kubernetes release blog.** The Communications team writes the release blog, which is the official announcement of the Kubernetes release.
+* **Collection of Major Themes.** The Communications team coordinates with SIG Leads to solicit Major Themes for the release, to be used in both the Release Blog and Release Notes.
+* **Authoring the Kubernetes release blog.** The Communications team writes the release blog, which is the official announcement of the Kubernetes release. This includes the Major Themes from SIG leads.
 * **Coordination and support of the feature blog series.** SIGs opt-in to author feature blogs for the release. These blogs are written by technical owners, and the Communications team supports authors from the early stages through facilitating editorial and tech reviews as well as publication.
 * **Coordination and support of an optional Deprecations and Removals blog.** Depending upon the content of a given release, it may be necessary to prepare the community for upcoming deprecations and removals. This is decided per release cycle around the time of Code Freeze.
 * **Scheduling press activities and the post-release webinar with the CNCF.** The Communications Coordinator works with the CNCF to schedule press release activities around the release, and to schedule the release webinar (typically scheduled 3-4 weeks post-release).
 
+### Collect Major Themes
+
+A GitHub Discussion must be open to invite all SIG leads and members to add Major Themes for inclusion in the Release Blog and Release Notes. The discussion must be opened in kubernetes/sig-release under General Category. Past discussions: [1.25](https://github.com/kubernetes/sig-release/pull/1987), [1.24](https://github.com/kubernetes/sig-release/discussions/1868), [1.23](https://github.com/kubernetes/sig-release/discussions/1709), [1.22](https://github.com/kubernetes/sig-release/discussions/1575), [1.21](https://github.com/kubernetes/sig-release/discussions/1436).
+
+In the case of a low reponse rate in the Github discussion, each SIG should be pinged via their individual Slack channels and the #chairs-and-techleads channel.
+
+The Communications team should hold a meeting to discuss Major Themes sometime around Code Freeze. Ensure that at least one person from the Release Notes team attends this meeting with the Release Lead and Enhancements Lead.
+
 ### Release blog
 
 The Communications Coordinator along with the Comms shadows are responsible for authoring the official Kubernetes Release blog. This blog is the official statement of release. The release blog is the primary vehicle by which the release team communicates the major themes, known issues, and other aspects of the release to the community. 
@@ -216,6 +225,7 @@ This is an example of a typical release cycle and the order of how tasks will fl
         <ul>
         <li>Work with the enhancements lead to understand big-ticket items to be included in the release
         <li>Start monitoring the <code>Feature blog opt-in</code> sheet for new entries and use the <code>Assigment tab</code> sheet to assign and track status throughout the cycle (<a href="https://docs.google.com/spreadsheets/d/1hgFWig6YBSYORP3huwEyU0VlXGcYi6wMxjYW-swzCIY">for example</a>)
+        <li> With Enhancement freeze in effect, create a GitHub discussion (<a href="https://github.com/kubernetes/sig-release/discussions/2047">example v1.26</a>) to start collecting the major themes of the release, and reach out to all SIGs on and off over the next few weeks to ask for major themes and explain why this is important to the community.
         <ul>
         </ul>
         </ul>
@@ -251,6 +261,7 @@ This is an example of a typical release cycle and the order of how tasks will fl
         <ul>
         <li>Send out final reminders for feature blog opt-in on the SIG slack channels
         <li>Facilitate or start writing the optional Deprecations and Removals blog
+        <li>Coordinate with Release Notes to ensure major themes are checked in before Code Freeze.
         </ul>
         </td>
     </tr>
@@ -276,6 +287,7 @@ This is an example of a typical release cycle and the order of how tasks will fl
         <td>
         <ul>
         <li>Begin the release blog draft, if not yet started
+        <li>Host a meeting with the Release Lead, Enhancements Lead, and Release Notes to discuss the Major Themes to be highlighted in the release blog and ensure consistency with Release Notes
         <li>Optional 'Deprecations and Removals' blog ready for review
         <li>Schedule the release Live Webinar with CNCF by emailing <code>webinars@cncf.io</code>. You may be referred to <a href="https://calendly.com/cncfonlineprograms">Calendly</a>. The webinar is typically scheduled for 3-4 weeks after the release
         <li>Schedule press and analyst pre-briefings and interviews for the release lead with CNCF by emailing <code>pr@cncf.io</code>
@@ -290,7 +302,7 @@ This is an example of a typical release cycle and the order of how tasks will fl
         <ul>
         <li>Finalize and publish the 'Deprecations and Removals' blog once code freeze is in place.
         <li>Update release blog draft, post-Code Freeze
-        <li>Check status with Release Notes lead on content for Major Themes and Known Issues sections of the release blog (short summaries to be included in the release blog)
+        <li>Check status with Release Notes lead on content for the Known Issues section of the release blog
         <li>Check status on all feature blog PRs. Keep <code>#sig-docs-blog</code> up-to-date for editorial review, and establish tech reviewers are available 
         </ul>
         </td>