Kubernetes Release: Escalation, Milestone Maintainers, and Adding Items

- PR is potentially de-stabilizing and is not needed to resolve a blocking issue - PR is a new, late feature PR and has not gone through the enhancements process or the [exception process][exceptions] - There is no responsible SIG willing to take ownership of the PR and resolve any follow-up issues with it - PR is not correctly labelled - Work has visibly halted on the PR and delivery dates are uncertain or late While members of the Release Team will help with labelling and contacting SIG(s), it is the responsibility of the submitter to categorize PRs, and to secure support from the relevant SIG to guarantee that any breakage caused by the PR will be rapidly resolved. Where additional action is required, an attempt at human to human escalation will be made by the Release Team through the following channels: - Comment in GitHub mentioning the SIG team and SIG members as appropriate for the issue type - Emailing the SIG mailing list - bootstrapped with group email addresses from the [community sig list][sig-list] - optionally also directly addressing SIG leadership or other SIG members - Messaging the SIG's Slack channel - bootstrapped with the slackchannel and SIG leadership from the [community sig list][sig-list] - optionally directly "@" mentioning SIG leadership or others by handle ## Adding An Item To The Milestone ### Milestone Maintainers The members of the [`milestone-maintainers`](https://github.com/orgs/kubernetes/teams/milestone-maintainers/members) GitHub team are entrusted with the responsibility of specifying the release milestone on GitHub artifacts. This group is [maintained](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers) by SIG Release and has representation from the various SIGs' leadership. Adding the in-progress release milestone to pull requests after the Code Freeze is strictly prohibited, as it can compromise the stability of the release. Prior to making such changes, approval must be obtained from both the Release Team Lead and the Emeritus Advisor(s). ### Feature additions Feature planning and definition takes many forms today, but a typical example might be a large piece of work described in a [KEP][keps], with associated task issues in GitHub. When the plan has reached an implementable state and work is underway, the enhancement or parts thereof are targeted for an upcoming milestone by creating GitHub issues and marking them with the Prow "/milestone" command. For the first ~4 weeks into the release cycle, the Release Team's Enhancements Lead will interact with SIGs and feature owners via GitHub, Slack, and SIG meetings to capture all required planning artifacts. If you have an enhancement to target for an upcoming release milestone, begin a conversation with your SIG leadership and with that release's Enhancements Lead. ### Issue additions Issues are marked as targeting a milestone via the Prow "/milestone" command. The Release Team's [Bug Triage Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md) and overall community watch incoming issues and triage them, as described in the contributor guide section on [issue triage](https://k8s.dev/docs/guide/issue-triage/).

The Release Team escalates issues through GitHub comments, email, and Slack, involving SIG teams and leaders. Milestone Maintainers, maintained by SIG Release, are responsible for specifying the release milestone. Adding the in-progress release milestone to pull requests after the Code Freeze is strictly prohibited. Feature planning involves creating GitHub issues marked with the Prow '/milestone' command. For enhancements, communication with SIG leadership and the Release Team's Enhancements Lead is essential. Issues are targeted using the Prow '/milestone' command, with triage conducted by the Release Team's Bug Triage Lead.