[ANNOUNCE] New triage workflow in kubernetes/kubernetes repo
Bob Killen
Hey there all,
There’s some changes being rolled out by the end of the day, Wednesday (September 30th), to the labels and workflow[1] for the kubernetes/kubernetes[2] repo that you should be aware of.
TL;DR:
New Issues and PRs will have an additional needs-<foo> label called needs-triage
Old Issues and PRs will be updated only if they undergo a label change.
The label can be removed by applying the triage/accepted label.
It can be applied with /triage accepted command by org members, and is used as a signal by SIGs that they have evaluated the issue or PR.
Please do not apply the triage/accepted label without consulting your SIG first.
The triage/support label is being renamed to kind/support.
Issue Triage Docs[3] will be updated in coordination with the rollout.
New Triage Workflow
Managing the incoming issues and PRs to the kubernetes/kubernetes[2] repo has been difficult. This has led to a multitude of issues/PRs falling through the cracks and eventually rotting out. To help prevent this, and to better prioritize incoming work some new labels are being introduced.
An additional required label[4] called needs-triage will be applied automatically to all new issues and PRs created within the kubernetes/kubernetes[2] repository similar to the current needs-sig or needs-kind labels, however unlike those other required labels, needs-triage will NOT prevent a PR from being merged. This is intended to serve as a boolean signal to community group members that the issue or PR has not yet been triaged. Old Issues and PRs will have the needs-triage label applied when their label state changes. This should prevent any potential exhaustion of our GitHub tokens.
After the issue or PR has been evaluated, an org member can apply the triage/accepted label using the /triage accepted bot command. This signals that the issue is ready to be worked on, or the PR is ready to be reviewed. If the issue is a duplicate or lacks supporting evidence one of the other triage labels[5] can be applied.
While any kubernetes org member may apply a triage label, please consult with the SIGs you’re involved with first. Several groups are planning to specifically use it in issue triage sessions, applying it out of band may cause the issue/PR to miss being evaluated.
Re-categorize the triage/support label
The other smaller thing you should be aware of, is the triage/support label has been recategorized to kind/support. This makes more logical sense as it specifies the “kind” of thing an issue is. Please remember that support issues should be encouraged to be posted on our forums (https://discuss.k8s.io), and then closed.
End user support questions in the kubernetes/kubernetes repo should always be referred externally, unless it is believed to be an actual bug. For more information, see our Issue Triage guidelines[6].
If you have any questions, please feel free to follow up with this email, or or the #sig-contribex channel in slack.
- Bob on behalf of SIG ContribEx
[1]: https://git.k8s.io/enhancements/keps/sig-contributor-experience/1553-issue-triage
[2]: https://github.com/kubernetes/kubernetes
[3]: https://k8s.dev/docs/guide/issue-triage/
[4]: https://github.com/kubernetes/test-infra/pull/19272/files#diff-8e2c107f040aaa80f29b8ee1c34b4a28
[5]: https://github.com/kubernetes/kubernetes/labels?q=triage
[6]: https://k8s.dev/docs/guide/issue-triage/#support-requests