RFC: issue/PR lifecycle & triage workflow changes

[Tim Allclair]

Proposed change: https://github.com/kubernetes/test-infra/pull/28266

Fixes "Auto-closing issues is harmful and causes friction" (kubernetes/kubernetes#103151)

Proposed changes:

1. Don't auto-close triaged issues, don't mark triaged issues & PRs as stale/rotten - Triaged issues & PRs have already been vetted by an org member as being relevant and having sufficient information. By ignoring triaged issues & PRs for lifecycle changes, this should reduce a lot of unnecessary churn & friction for maintainers.

2. Require issues & PRs that have been unchanged for > 1 year to be re-triaged - This essentially adds a new lifecycle stage with a much greater (1 year vs 90 days) window. The idea is that the project changes a lot in 1 year, and it makes sense for issues that have been untouched for that amount of time to be retriaged, to ensure they are still relevant. Note that once the triage label is removed, the regular stale/rotten/closed lifecycle checks kick back in.

[Tim Allclair]

+SIG-Contribex (first email bounced since I needed to join the group)

Please respond with feedback on the PR, and not to this email thread, to avoid bifurcating the conversation.

[Tim Allclair]

This topic was discussed at the last SIG-contribex meeting, and there was general agreement on the direction. We're still working out some of the details on the PR, but plan to merge this sometime this release cycle. If you still have feedback, it's not too late to chime in on the PR! https://github.com/kubernetes/test-infra/pull/28266

Summary of changes from the original proposal:

- Triage rules only apply to issues, lifecycle workflow on PRs is unchanged (ignore the triage/accepted label, stale after 90 days of inactivity)

- Re-triage is more aggressively required for critical-urgent (30 days) and important-soon (90 days) issues

Thanks!

[Benjamin Elder]

Does this mean marking an issue as more critical will reduce the time it will stay open??

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-con...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-contribex/CALXpagyJwdH9wWGea8k362zsi-5SVZUQUVTADsSge_x5RcTEAQ%40mail.gmail.com.

[Tim Allclair]

I responded on the PR to avoid bifurcating the discussion: https://github.com/kubernetes/test-infra/pull/28266#issuecomment-1404096714

[Tim Allclair]

These changes have just been merged. To recap, the final set of workflow changes are:

1. Don't auto-close triaged issues, don't mark triaged issues as stale/rotten - Triaged issues have already been vetted by an org member as being relevant and having sufficient information. By ignoring triaged issues for lifecycle changes, this should reduce a lot of unnecessary churn & friction for maintainers.
2. Require issues to be retriaged when untouched for a set amount of time - This essentially adds a new lifecycle stage with a variable length window, depending on priority. Higher urgency issues (critical-urgent & important-soon) will require more frequent retriage. Note that once the triage label is removed, the regular stale/rotten/closed lifecycle checks kick back in.
   • critical-urgent - retriage after 30 days of inactivity. Critical-urgent issues must be actively worked on as someone's top priority right now.
   • important-soon - retriage after 90 days of inactivity. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.
   • else - retriage after 1 year of inactivity
3. Don't auto-close important issues - Issues labeled with priority/critical-urgent, priority/important-soon or priority/important-longterm will no longer be auto-closed from the lifecycle/rotten state (but can still be marked stale and rotten)
4. Remove the job that marks important triaged issues as frozen - This is redundant with the changes in (1) and (3).

Please let me know if you run into any problems with the new processes.

Thanks!

-- Tim Allclair