search

kubernetes / test-infra

Test infrastructure for the Kubernetes project.
Apache License 2.0
3.83k stars 2.65k forks source link

don't re-triage all issues annually #32957

Open BenTheElder opened 4 months ago

BenTheElder commented 4 months ago

We were discussing in the api-machinery triage meeting that there are some issues fitting a pattern like:

help-wanted, lifecycle/frozen, triage/accepted

Which are:

re-triaging them annually doesn't really add information, if anything it buries the actual discussion under bot comments + /triage accepted comments, closing them buries the context on why they haven't been resolved.

I think we should only re-triage issues that are not frozen, or issues that are not frozen and marked help-wanted. (IMHO any frozen issue, but the former would still help)

Issues that are frozen + help-wanted are a searchable way to say "yes we know about this, but someone will have to step up and solve it, here is the context".

For example: https://github.com/kubernetes/kubernetes/issues/104607 This issue is complicated to fix, but in the meantime it remains confusing and should be documented.

Currently the bot will annually remove triage/accepted from all issues, even ones with this label set that are effectively "this is known and we need help".

I strongly believe closing https://github.com/kubernetes/kubernetes/issues/104607 is unhelpful and further buries this confusing behavior, but I also understand that none of us currently have the time to resolve it. So for now we're just re-triaged it again.

/sig contributor-experience

thockin commented 4 months ago

I agree. I love the re-triage effort, but if someone has taken the (rather extraordinary) step of freezing an issue, it's probably not the sort of thing that we need to re-triage. I think we have a signal-to-noise problem in a few places, this is one.

jpbetz commented 3 months ago

+100. We get a batch of these, time warped in from the past, each week. The frozen ones just create noise.

tallclair commented 3 months ago

The idea of retriaging was to make sure the issue is not obsolete, and reprioritize as needed. If it's creating too much noise as is, maybe we should consider increasing the interval rather than removing it entirely?

BenTheElder commented 3 months ago

The idea of retriaging was to make sure the issue is not obsolete, and reprioritize as needed. If it's creating too much noise as is, maybe we should consider increasing the interval rather than removing it entirely?

But frozen issues are intentionally opted into long term tracking to prevent auto-close, if people want to opt-in to identify if old issues are still valid that's great, but automatically re-triaging frozen issues seems excessive.

We shouldn't be closing frozen issues without high confidence and these comments are always noise that buries real non-automated discussion, unless they result in a valid closure. GitHub does not and never has supported issues with a large volume of comments well, the cost of annually adding at least two comments with no additional information beyond "yes we didn't decide to close it again" seems pointless.

If we want to re-validate issues we can look through older frozen issues without robot comments, anyone can just query for label:lifecycle/frozen label:triage/accepted and start from the last page of results without adding noise to the issues.

EDIT: Leaving them open has very little cost and almost no downsides. We're not really running into anywhere that the number of open issues is a constraint ..?

k8s-triage-robot commented 3 weeks ago

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

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

You can:

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

/lifecycle stale

BenTheElder commented 3 weeks ago

/remove-lifecycle stale

cc @kubernetes/sig-contributor-experience (previously raised in slack)