Update process and release team handbooks handbooks on Major Themes

[fsmunoz]

The current process, as documented in the handbooks, is broadly like this:

1. Release Notes team opens a Major Themes issue
2. Release Notes team goes after SIGs to get content
3. Comms uses the information to build the release announcement
4. Release Notes uses the information (perhaps indirectly by reusing the content made by Comms for the announcement) for adding a What's New (Major Themes) section in the release notes

In reality, 1.25 was the last release in which the release notes included a Major Themes section, for reasons that were discussed and approved by the release teams at each subsequent release, but the process was never updated: this leads to a confusing situation in which the release notes team is responsible for collecting information that it will not use, and Comms also goes after SIGs for content.

In the 1.29 release, we re-added the Major Themes section, but with a simple paragraph that mentions the release name and links to the release article, avoiding duplicating content.

Assuming that this approach is adequate, we need to update the handbooks (namely, the Release Notes and the Comms handbooks) to reflect this. If it isn't adequate, we should identify an alternative that is consistent across teams.

[fsmunoz]

/kind feature
/priority important-longterm

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten