[bassdropvroom]

I disagree. It entirely depends on the behaviour.

I've lost count of the number of tickets that have been raised that has no information, or is not reproducible, or something else. When I then ask for more information, or something else, they never reply. I've no incentive to keep such tickets open.

So I set up stale bot and auto-close the tickets. Individuals can come and re-open if it happens to them, or more information is added.

Now I do agree, if it is a genuine issue, then it shouldn't be closed until it is sorted out it. So you can set up stale bot to ignore labelled or something. So that's how I've set up all of my repos. For me this has taken off a huge burden.

I don't agree with locking threads after they've closed though. There is very little reason to do so.

[kubajastrz]

One way that I found out recently in the vite github repository [0], is to use github actions cron job to automatically close issues with certain labels, like "needs reproduction".

This way maintainers need to at least explicitly set the label before the issue is closed automatically, and not the other way around.

[0]: https://github.com/vitejs/vite/blob/b6d12f71c1dbd5562f25bc2c...

[eptcyka]

This is different from closing legitimate bugs/issues that are well described and testable, just not fixed.

[bassdropvroom]

That's right. It's all use-case based. Indiscriminately closing issues automatically is definitely wrong. Automatically closing issues that cannot be reproduced or have other issues is a perfect use-case for stale bot.

[eptcyka]

Show me a bot that can tell the difference between a testable and well described bug and one that's affecting lots of users but has bad descriptions.

[bassdropvroom]

Using GitHub's stale bot you can set it to ignore labelled issues, and so it's up to maintainer to label things correctly. Once the maintainer does so, stale bot won't touch it.

[mook]

I believe that's backwards — it requires active effort from the maintainer (who may be on vacation) to prevent closing, when the ball is in the maintainer's court (to check if it's a reasonable ticket). The process described elsewhere in this subthread, where the maintainer has put a label on the issue before it can be auto-closed, is better (since the next action is on the reporter); that must only happen if the reporter hadn't responded, though.

[eptcyka]

How is that different from someone closing the issue manually?

[hinkley]

I think the problem is that the bot is the wrong solution to the problem.

It's like when I was clearing out my inbox of spam - about 10% of the garbage was legitimate spam, the rest was self-inflicted spam - ads for places I frequent, and mailing lists that I kept thinking I would read 'some day'.

What I needed was a way to group all of the suspicious messages so that I could machine gun my way through them spending less than a couple of seconds each. First hour got a lot of dead messages quickly, slowing down over time and totaling about 4k messages by hour four (most of that spent in front of a TV, which let me finish but also made it take longer - if you ignore the divide by zero error).

What you need is a way to tag suspicious issues so that you can go through and veto the 20 that are legit, and delete the rest. But that may require some feature requests to GitHub, and a different bot.