Don't auto-close triaged issues, require re-triage after 1yr

[tallclair]

Fixes kubernetes/kubernetes#103151

This PR makes the following workflow changes (separate commits):

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 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.
   • critical-urgent - retriage after 30 days of inactivity
   • important-soon - retriage after 90 days of inactivity
   • important-longterm and backlog - 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.
4. Remove the job that marks important triaged issues as frozen - This is redundant with the changes in (1) and (3).

/hold
for comment

/sig contributor-experience

[thockin]

FWIW I am +1 on the idea

[lavalamp]

Both changes sound great to me!

[SergeyKanzhelev]

I would caution about complicating stale/rotten flow. For example, if triaged PRs will not be marked stale or rotten, there will need to be an exception for PRs that are waiting on author. For example, ones that needs a rebase for a prolonged duration of time are better be staled and closed by robot. In fact we even want to speed up this process. For issues, we may need to make a special case for priority/backlog: stale and rotten. Typically backlog issues are not absolutely required and in the lack of signal they may be fine to be closed.

Perhaps the better option will be to un-triage everything that got staled or rotten. Same as the item 2 in proposal, but faster. Re-triaging is an opportunity to assign somebody to the issue during the triage. And having more opportunities to do it (every 30 days vs. 1 year) is better.

Just my couple cents

[tallclair]

I can see the argument for keeping the current process for PRs. Sometimes we do intentionally hold PRs for a release, but I think the 3 month window for marking stale is still OK for that.

For issues, one of the problems I'm hoping to address with this is the amount of churn that the current automation creates on maintainers. Everytime I check my github inbox for issue updates, approximately half of them are just bot comments marking issues as stale (and people unmarking them).

[sbueringer]

For issues, one of the problems I'm hoping to address with this is the amount of churn that the current automation creates on maintainers. Everytime I check my github inbox for issue updates, approximately half of them are just bot comments marking issues as stale (and people unmarking them).

I agree and have the exact same experience.

And having more opportunities to do it (every 30 days vs. 1 year) is better.

Having to re-triage everything every 30 days sounds like a lot of work for maintainers.

[SergeyKanzhelev]

And having more opportunities to do it (every 30 days vs. 1 year) is better.

Having to re-triage everything every 30 days sounds like a lot of work for maintainers.

I don't disagree. But the same time keeping priority/important-soon issues for a year without touching is not ideal either. Those needs to be looked at or priority lowered. Maybe this time can be increased for issues marked as priority/backlog

[MadhavJivrajani]

I am +1 to this change in general. One comment:

And having more opportunities to do it (every 30 days vs. 1 year) is better.

Having to re-triage everything every 30 days sounds like a lot of work for maintainers.

I don't disagree. But the same time keeping priority/important-soon issues for a year without touching is not ideal either. Those needs to be looked at or priority lowered. Maybe this time can be increased for issues marked as priority/backlog

I think this is a very valid point. From the documentation of priority/important-soon:

Must be staffed and worked on either currently, or very soon, ideally in time for the next release.

Although often label description and how they're used differ, I think priority/{important-soon,critical-urgent} and release-blocker are two that are good candidates to consider based on how they're used.
(I don't think release-blocker or even critical-urgent is going to be an issue but for the sake of completeness).

We should consider excluding these and re-prioritising if the current cycle kicks in. The new cycle for priority/backlog / no priority label sounds great.

[tallclair]

I'm open to having a different ruleset for priority/{important-soon,critical-urgent}. What are the proposed changes for those? Just keep the current workflow (ignore triage/accepted)? Or should we keep the same workflow (remove triage first), but just be much more aggressive about removing the label?

I'm leaning towards the second option, of removing triage/accepted more agressively for important issues. Maybe 3 months for priority/important-soon and 1 month for priority/critical-urgent? Or is a separate timeline for those too agressive?

[tallclair]

With regard to moving important issues to backlog, we'll need a separate commenter rule for important issues, so the bot comment can just explain the expectations for important issues, and suggest reprioritizing them.

[mrbobbytables]

I am also in general support of this idea 👍

[SergeyKanzhelev]

Removing triage label before it went stale is a good idea. I wonder if the very first comment to triage it back will simply extend the stale period. One thing we can consider is stale AND remove triage at the same time. This will give a better signal to triager that the issue needs attention

[tallclair]

/assign @BenTheElder

For implementation review

[BenTheElder]

/lgtm
/approve
this looks right, I think

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: BenTheElder, tallclair

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• config/jobs/kubernetes/sig-k8s-infra/trusted/OWNERS [BenTheElder]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tallclair]

/hold cancel
/label tide/merge-method-squash

[BenTheElder]

/lgtm

[k8s-ci-robot]

@tallclair: Updated the job-config configmap in namespace default at cluster test-infra-trusted using the following files:

• key sig-contribex-k8s-triage-robot.yaml using file config/jobs/kubernetes/sig-k8s-infra/trusted/sig-contribex-k8s-triage-robot.yaml

In response to this:

Fixes kubernetes/kubernetes#103151

This PR makes the following workflow changes (separate commits):

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 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.
   • critical-urgent - retriage after 30 days of inactivity
   • important-soon - retriage after 90 days of inactivity
   • important-longterm and backlog - 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.
4. Remove the job that marks important triaged issues as frozen - This is redundant with the changes in (1) and (3).

/hold
for comment

/sig contributor-experience

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[sbueringer]

@tallclair I think this is missing is:pr

[sbueringer]

xref: an example kubernetes-sigs/cluster-api#5863 (comment)

[sbueringer]

Should this be 720h?

[tallclair]

🤦‍♂️ thanks!

#28691