I have never seen the @Stale bot or any directly equivalent to it achieve a net positive outcome. Never. It results in disgruntled people, extra expenditure of effort (for reporters and maintainers), real stuff getting lost when people get fed up with poking the bot (I have no intention of poking it further), and more extensive filing of duplicates. You say a simple comment dismisses it, but it doesn’t—it only does this time. Next time, it continues to annoy. This is an issue tracker. Use labels, projects, milestones and the likes for prioritising stuff. Not sweeping stuff under the carpet.

It is an issue tracker but we don't have a backlog, or planning sessions, or a project board. Or the resources to even triage and tag effectively. If it is important someone will respond / reopen, popular issues are exempt from the bot, we can't fix everything and this is pretty much our only view on stuff that need to be addressed. We need to make some attempt to make sure that everything is still relevant and reduce the noise to a degree where we can actually manage it. I understand the trade-offs with stale bots but we don't have many options. I appreciate your experiences but that doesn't make them a fact. We have discussed this internally and this is what we are doing. If you have any other actionable alternatives outside of saying the bot is bad then we are all ears.

Closing issues doesn’t solve anything. Closing issues in GitHub just sweeps them under the carpet and helps everyone to forget about them, which is just not what you want—the fact that GitHub search excludes closed items by default is a large part of the problem with it. As applied to software projects with general-purpose issue trackers, the @Stale bot is fundamentally phenomenally bad idea, a road paved with good intentions. I presented an actionable alternative: labels. Possibly automatically applied, but it’s certainly better to spend a little bit of time on manual triage. It honestly doesn’t take long to skim through a few hundred issues and bin them into labels. 609 open issues? That’s honestly not a problem. Not at all. There’s nothing wrong with having a large number of issues open, if they do correspond to real things—even things that you may not expect to get to for years, if ever, because that might change or someone might decide they want to deal with one. Closing issues that aren’t dealt with is bad. Please don’t do it.

Most issues have been manually labelled as stale rather than automated and closure will be manual too, so we have time to think.

About auto-close bots... I can appreciate the need for issue grooming, but surely there must a better way about it than letting an issue or PR's fate be semi-permanently decided and auto-closed by an unknowing bot. Should I be periodically pushing up no-op commits or adding useless "bump" comments in order to keep that from happening? I know the maintainers are busy people, and that it can take a long time to work through and review 100s of open issues and PRs, so out of respect to them, I was just taking a "be patient; they'll get to it when they get to it" approach. Sometimes an issue is not so much "stale" as it is unnoticed, forgotten about, or consciously deferred for later. So if anything, after a certain length of time, if a maintainer still hasn't reviewed/merged/accepted/rejected a pull request, then perhaps it should instead be auto-bumped, put on top of the queue, to remind them that they (preferably a human) still need to review it and make a decision about its fate... :)