don't re-triage all issues annually

[BenTheElder]

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:

• valid known issues
• lacking sufficient staffing to address
• contain context on why the issue has not been resolved

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: kubernetes/kubernetes#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 kubernetes/kubernetes#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]

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]

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

[tallclair]

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]

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]

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

[BenTheElder]

/remove-lifecycle stale

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

[BenTheElder]

Hi @kubernetes/sig-contributor-experience, what would it take to discuss potentially acting on this recommendation? The configuration changes proposed are small and I think will incrementally improve signal-to-noise on the triage robot and avoid wasting time.

[BenTheElder]

Per @palnabarun: cc @kubernetes/sig-contributor-experience-leads 😅

xref: kubernetes/community#8047

[jberkus]

+1 from me.