sig-release: Document priority labels for issues related to CI failures/flakes

The CI signal handbook reads at the moment:

Make sure all open issues have a priority/ label

but does not document what priority labels are available and what the thought process is for using each of them, specifically in the context of issues created for CI failures and flakes.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 20 (20 by maintainers)

Most upvoted comments

For reference, from https://go.k8s.io/github-labels

Name Description Added By Prow Plugin
priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. anyone label
priority/backlog Higher priority than priority/awaiting-more-evidence. anyone label
priority/critical-urgent Highest priority. Must be actively worked on as someone’s top priority right now. anyone label
priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. anyone label
priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. anyone label

These are shortened summaries of https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority

We try to apply these priority labels consistently across the entire project, but if you notice an issue that you believe to be incorrectly prioritized, please do let us know and we will evaluate your counter-proposal.

  • priority/critical-urgent: Must be actively worked on as someone’s top priority right now. Stuff is burning. If it’s not being actively worked on, someone is expected to drop what they’re doing immediately to work on it. Team leaders are responsible for making sure that all the issues, labeled with this priority, in their area are being actively worked on. Examples include user-visible bugs in core features, broken builds or tests and critical security issues.
  • priority/important-soon: Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
  • priority/important-longterm: Important over the long term, but may not be currently staffed and/or may require multiple releases to complete.
  • priority/backlog: There appears to be general agreement that this would be good to have, but we may not have anyone available to work on it right now or in the immediate future. Community contributions would be most welcome in the mean time (although it might take a while to get them reviewed if reviewers are fully occupied with higher priority issues, for example immediately before a release).
  • priority/awaiting-more-evidence: Possibly useful, but not yet enough support to actually get it done. These are mostly place-holders for potentially good ideas, so that they don’t get completely forgotten, and can be referenced /deduped every time they come up.

I’ve been around to see these go from priority/P# to these much longer label names, and sorta question whether the label names have helped at all.

But, in lieu of addressing that, I think at least consistent guides for how this team applies the labels would be helpful. I feel like CI Signal owns (or should be able to claim ownership of) label hygiene for is: issue milestone:v1.14 label:kind/failing-test and is: issue milestone:v1.14 label:kind/flake