Auto-close old issues where the reporter doesn't follow up

[cvrebert]

Refs btford/mary-poppins#21
Basically, have a bot that periodically checks for currently-open issues have had an "awaiting reply" tag for at least N days without any subsequent posts by non-twbs-team users, and closes them with a nice explanatory comment.

[hnrch02]

I think I need to report you to some authority, you are creating way too many bots 😝
Seriously though, I like the idea. As I've said before, we should generally introduce more tags labels. I'll write up some I had in mind soon.

[cvrebert]

s/bots/microservices/
They're all the rage these days ;-)

[juthilo]

👍

[mdo]

I can dig it I think.

[XhmikosR]

Makes total sense 👍

[cvrebert]

Created a stub: https://github.com/cvrebert/no-carrier
Currently blocked by https://github.com/cvrebert/no-carrier/issues/1

[cvrebert]

Submitted a patch to EGit-GitHub to fix the blocker: https://git.eclipse.org/r/#/c/35781/

[cvrebert]

Relatedly, what do y'all think of auto-locking closed issues where the last comment was N months ago? The GitHub API for issue locking doesn't exist yet, but a Supportocat said it is planned.
This would prevent necroposting.

[hnrch02]

@cvrebert Don't know how I feel about that yet. What threshold did you have in mind? Also, would the new microservice comment on it before locking it?

[cvrebert]

3 months since last comment? Yes, it would post a final explanatory comment.

[hnrch02]

Yeah, that sounds reasonable. And it would have its own GitHub account, I presume?

[cvrebert]

I'd probably make the closer and the locker a single program+account.

[acshef]

Is it wise for a bot to come through and close things without warning? Perhaps it makes an informative warning post beforehand: "This issue has been open for 83 days since last reply. If a reply is not posted within the next 7 days, this issue will be automatically closed."

[cvrebert]

The 90-day timeframe is for auto-locking already-closed issues. Those issues have already died a natural death; we don't want to stimulate them by posting a comment.

The auto-closing feature is separate and the timeline will be much shorter. And mere closing isn't permanent; we're quite willing to reopen issues if folks do end up getting back to us.

[acshef]

Fantastic -- thanks for the clarification!

[kkirsche]

@cvrebert While testing in Bootstrap is good in regards to regressions, would this mean the preferred action would be to X-Ref the old issue from a new one stating that Component XYZ has regressed to with same issue XXXX instead of re-opening an existing issue for a regression?

Sorry if that didn't make sense. Basically just open a new issue for regressions or comment and reopen old ones if the issue arises again

[cvrebert]

@kkirsche Yes. A new issue is a much better way to get our attention as maintainers, and folks sometimes incorrectly think a new problem is related to an old issue because the symptoms might be kinda similar, when in fact the underlying cause ends up being unrelated, in which case reopening would be semantically wrong.

[mdo]

Does this need to be open here, or could we perhaps use another public repo to track these kind of meta things? Things like new bots, org level changes, etc.

[cvrebert]

I am happy to report that this is now nearly done. I am mostly waiting on some fixes to an upstream library that will allow my project to have thorough unit tests for its GitHub interactions.

Refs: jcabi/jcabi-github#1055, jcabi/jcabi-github#1056, jcabi/jcabi-github#1063

[cvrebert]

Blocked on one last PR: jcabi/jcabi-github#1068

[cvrebert]

(sigh) Had to bifurcate that PR, so there's still one to go: jcabi/jcabi-github#1073

[cvrebert]

Yay, the bot is finally ready! I hope to deploy it soon, pending discussion and final approval from the other members of the Core Team.

The auto-locking feature has been punted to https://github.com/cvrebert/no-carrier/issues/3