Compare it to the Istio project which just deletes your issue if someone doesn't respond it to after 28 days. Despite the issue often being quite real.
Also I wonder how these larger projects will fare once Github rolls out the Discussions feature.
The only reason I knew those github issues existed in the first place was because I wasted hours (sometimes days) of my life looking into an issue only to eventually stumble upon them and realize its a bug and I'm not "holding it wrong". Good luck to the next person that goes spelunking on the internet for help on those issues.
Reminds me of: https://xkcd.com/979/
I think having a bot tag, but not close, issues over a certain age, seems to make a lot of sense.
Sure, you have closed the issue because you did not pay attention to it for the last year. But the problem is still there. So the next person who stumbles upon the old, locked issue will now open a new one. Now you have two issues.
Whenever I came across these issues, I'd just open up a new issue and link to the old one and politely ask if they planned on addressing it or not.
The quest for the perfect issue grooming continues.
Example: https://github.com/microsoft/vscode/issues/86409#issuecommen...
And auto-closing doesn’t mean the issue can’t be reopened. If OP posts additional information after the grace period, the maintainers will be notified and the ticket can be reopened.
But in the end, whatever works for you!
In this case, wouldn't it fall under being "not accurate" if the issuer doesn't supply requested information showing that it's accurate?
There are two common cases where some automation can help:
- User reports bug, dev explains that "it's not a bug, here's why, xxx" (or otherwise provides a satisfactory response) and user, even if satisfied, fails to return to close bug. So instead devs have to remember to close the bug which they usually do immediately after responding, which comes off as abrupt, even though it's not meant that way.
- User reports bug, dev responds with request for more info ("I can't duplicate; could you provide a better test case?"), user never responds.
In both cases it's OK to time out these old reports (which are essentially clutter). You could provide a way for the dev to flag this as one not to be auto-cleaned up.
Another improvement, while I'm at it: provide a Godbolt-like way to submit a test case that can be outrun (i.e. a CI case). Then the bug could be auto-closed if it's in the current release but already fixed in the dev sources. Not all bugs or applications could take advantage of this of course.
I also don’t like them, but it does force the reporter to stay engaged and bump issues they really care about.
Issue management seems like a major surface for Github to improve on.
I have a work category for each of my projects named simply “ticket laundry” and I know it eats up a lot of time for maintainers and reporters.
Here's a nice write-up I found: https://dzhavat.github.io/2020/04/04/my-thoughts-on-github-d...
Like the whole CLR telemetry thing.