Review and update 'stale' issues settings & process

[david-martin]

The current process for handling 'stale' issues isn't documented and could do with some tweaks to work better for the project & team.
There is a workflow at https://github.com/Kuadrant/multicluster-gateway-controller/blob/main/.github/workflows/stale-closer.yaml
However, there's a few oddities that I've noticed.

• 'stale' comments are created by the user @philbrookes e.g. Traffic Migration Policy #198 (comment) This makes me wonder who owns/runs the workflow? Is it that users account? What if that account were hacked or the user left the project? These comments would be better coming from a bot account than a user.
• There's no process around reviewing issues that have been marked as 'stale'. For example, this issue has been marked as stale after 30 days, and then closed after a further 30 days. A process should be put in place for the team to review issues marked as 'stale' and decide what the appropriate action is. e.g. add some label or comment requesting or adding information so it's no longer stale, or close it/let it be closed.
• Related to the previous point, it's not obvious what the issue author should do when their issue is tagged as stale. Perhaps the comment should include helpful information similar to this so the author can take better action.
• When 'stale' issues are eventually closed automatically after the 2nd 30 days of inactivity, they are marked as completed. Closing issues as not planned rather than completed would be more accurate.
• The 30 day x2 inactivity period may be a little low, given there are longer term roadmap items in the issue backlog. Let's increase those values so we don't end up reviewing and updating the same long term issues with arbitrary comments or labels just to keep them open longer. Based on the k8s-triage-robot, perhaps something like 90 days initially, then 30 days with a 'rotten' state, then closing the issue after another 30 days?

[philbrookes]

It's cool to see the stale closing of issues getting some discussion, my main goal when adding it was to avoid an enormous backlog like so many projects seem to accumulate. I hoped that addressing it early would avoid the requirement for radical actions later on after the backlog was already out of control.

Some thoughts on the points above:

• I think these issues are commented by "me" because the credentials I created for the workflow are in my account, this would probably be corrected by generating the credentials from a Kuadrant or bot account instead.
• I think a review of stale issues is a great idea (maybe at backlog refinement? Sorted by longest stale sounds good to me).
• We can definitely improve the wording of the stale comment to help guide a response to it.
• I used an existing github action to facilitate the staling(?) and closing of tickets, I'm not sure how configurable that is to introducing new states (like the suggested rotten) here's the docs for that github action, although we could definitely look to replace this with something else if it has insufficient configuration options.

[philbrookes]

Concerning the closing of issues that should remain open, we could look to add the exempt-issue-labels and exempt-pr-labels and mention that they can be labelled this way to avoid being closed as stale - though I would then suggest that these exempt issues should also be reviewed in the stale issues review.

[R-Lawton]

i agree i think 30 days might be to quickly to become stale, when we get further along and tickets are created that are good to do but might be pushed out to further sprints because of priority they would become stale but are still wanted.

Im not sure if we already take this into consideration but in terms of days until stale we could think about how many opportunities is there to pull that issue into refinement or into sprint, i.e in 30 days there's roughly 1 sprint so 1 sprint planning and 1 backlog refinement.

Something else i had a think about is a priority we could introduce a priority label which i think would be beneficial after the MVP to to show whats the next things we need to do coming down the road. Then if its doable in terms of configurations we could have lower priority tickets have longer times before they become stale and higher priority have a quicker time

In terms of when they should be checked, 10 mins at the start or the end of refinement could be good since if we get on top of them they shouldn't be to many

[philbrookes]

This issue is stale because it has been open for 30 days with no activity.

[philbrookes]

This issue is stale because it has been open for 60 days with no activity.

[philbrookes]

This issue was closed because it has been inactive for 30 days since being marked as stale.

[david-martin]

There's no stopping philbot if this issue closes :)

[philbrookes]

This issue is stale because it has been open for 60 days with no activity.

[philbrookes]

This issue was closed because it has been inactive for 30 days since being marked as stale.