Proposal to auto close old issues

[jedwards4b]

I propose that we add the github action https://github.com/marketplace/actions/close-stale-issues to cime to help us manage old issues and PRs.

What do you think?

[ekluzek]

I think this is a good idea to try out. The default times might be adjusted, but I think this might help us manage and sort through issues.

The length for closing of PR's should either be longer, and turn that feature off, as there are older PR's that are around. And I don't find sorting through PR's to be a problem, but issues certainly are.

[jedwards4b]

@ekluzek In the PR #4405 only issues are marked stale and auto closed, PR's are not.

[rljacob]

Lots of config options. It has "Labels on issues exempted from stale" which I think we should use for bugs that really should be fixed even if we never seem to have time to fix them. Just need a label for those.

[jedwards4b]

I would agree to that but propose we do at least one round without that flag first just to confirm that they are really still bugs.

[rljacob]

Sure. We wouldn't start adding that flag until after something was closed that shouldn't be.

[billsacks]

I know some repositories use this, but it has struck me as creating more work than it saves. I'm coming at this from a perspective that I would want to review an issue that was about to be auto-closed to confirm that it really should be closed. So then, when I get a notification that it's being auto-closed, I would need to prioritize looking through the issue at that time and possibly doing something to keep it open. This seems less efficient than just proactively going through all issues periodically (say, once or twice a year) and reviewing them to determine which should be closed.

To put this another way: I think there is a low correlation – at least in CIME and some of our other repositories – between the staleness of an issue and whether it should be left open or closed. So I don't think I would find it very helpful to have a script notify me that an issue is stale – instead, it would be more likely to just cause more frequent interruptions to my work with the need to make a decision.

[jedwards4b]

@billsacks I disagree - there is going to be one high impact point when this is implemented and all those old issues are marked, once the first round is purged there will just be a regular gentle reminder of the few issues marked stale.

[billsacks]

I'm willing to give it a try as long as we have a flag like @rljacob suggested.

[billsacks]

Okay, I'll admit: I'm coming around to this idea of auto-closing stale issues: this has been seeming like a good mechanism to identify issues that were created at one point but which people may not care about anymore.

[rljacob]

Yes and I like that its doing them in batches. Is the number of issues auto-closed per day a user-defined parameter?

[rljacob]

Also wondering how it picks which issues to close. It didn't start with our oldest issue (#119) and go forward.

[jedwards4b]

It does 30 issues in a batch and starting with the most recent, working it's way backward. @jasonb5 mentioned an option to start with the oldest issue, but we haven't set it.

[mvertens]

@jedwards4b - thanks for initiating this. I think its a great way to keep issues from accumulating to a huge number. We should definitely do this next in cmeps, cdeps, and the share code.

[rljacob]

moved to discussions so it can be found easier.

[rljacob]

Found this chrome extension that lets you move an issue to another project's repo. Github itself can only move issues between repos in a project. It adds a button to the issue web page. https://github.com/gatewayapps/kamino