Implement logic to find old 4 year old E-needs-mcve issues to close
#1746
Conversation
This is the first commit in a series of commits to implement the automatic triaging of old E-needs-mcve issues that was proposed and discussed in [t-release/triage] and cross-posted to [T-compiler]. This commit only implements the logic to find what the issues to close, and prints that info to stdout for inspection. Think of it as a dry run. After we have convinced ourselves this logic works as it should, we can implement the final steps: * Actually close the issue * Report closes to "triagebot closed issues" topic in "t-release/triage" Zulip [t-release/triage]: https://rust-lang.zulipchat.com/#narrow/stream/242269-t-release.2Ftriage/topic/auto-close.20E-needs-mcve/near/400273684 [t-compiler]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/auto.20closing.20E-meeds-mcve/near/399663832
Enselic
changed the title
E-needs-mcve issues to close
| on: | ||
| workflow_dispatch: {} | ||
| schedule: | ||
| - cron: "0 12 * * 1" # Every Monday at 12:00 UTC |
There was a problem hiding this comment.
Do we need to run this every week? What's the expected amount of new issues that will match this filter?
|
@jackh726 Hello! Before I close this PR I just wanted to check if you are still skeptical about doing it like this? Or have you changed your mind? If you have changed your mind I can keep working on it. |
|
I'd be happy to have triagebot pick a few issues a week meeting this criteria and just posting them to zulip, to "ping" people to look at them. From there, somebody can look to see if they 1) really have no repro at all (and if so, close) 2) have a repro but no MCVE, and maybe add like a MCVE-triaged label or something to make sure the bot doesn't get around to it (to be removed at some point when we don't need the bot) |
|
I still don't think these issues are an automatic candidate for closing, but I do think they're a great candidate for "hey, these are questionable and probably easy to triage", so I don't think it's worth just outright dropping this! |
|
I think it makes a lot of sense to turn this PR into "auto-closing of old S-needs-repro issues". Any objections? (If not I'll implement this some time in the future.) Kudos to everyone involved in getting S-needs-repro in place btw. |
|
I still think it's not a great idea to auto close old issues like that. Would still be very happy to see this as a zulip ping to look at issues (and actually, that logic is useful for other things too, so writing it is useful regardless) |
|
This has slipped down on my prio list, and I don't see myself getting time to resume work on this in the near future unfortunately. I don't like to keep PRs open indefinitely, so I will close this for now. |
This is the first commit in a series of commits to implement the automatic triaging of old E-needs-mcve issues that was proposed and discussed in t-release/triage and cross-posted to T-compiler. I have included the accepted (read: not objected) proposal below for the convenience of code reviewers.
This commit only implements the logic to find what the issues to close, and prints that info to stdout for inspection. Think of it as a dry run.
After we have convinced ourselves this logic works as it should, we can implement the final steps:
Current output of program
Accepted Proposal
I would like to propose that triagebot begins to close old E-needs-mcve issues.
Goal
The goal of this proposal is to achieve a net reduction in manual wg-triage work. It shall be less work to manually correct bot mistakes than to manually triage all affected issues.
Heuristics
Under this proposal, triagebot will close issues that
No such issue currently exist. But one year from now, the bot will have closed this list of issues, averaging at less than 2 issues closed per month.
I have looked at them all, and by my estimation they are all closable by the bot. In two cases (71257, 69169) it looks like E-needs-mcve should be removed, but that's fine. The bot will indirectly help them get removed by bringing this to the attention of a human. (Of course you may remove the labels already now if you wish, now that I brought it up.)
Auditing
To ease auditing, the bot will report all its actions in a Zulip topic called triagebot closed issues in the t-release/triage stream.
Closing comment
The bot makes this comment when closing an issue: