I share your loathing.

The stale bot will unhelpfully ask if "this is still an issue" or if something is being waited on for a pull request. You take the time out to reply, so that stale bot keeps the issue open. Repeat this meaningless back and forth, for months as the maintainers ignore the issue or pull request. Eventually lose the will to continue and let the bot close the issue or pull request.

Net outcome: A potential contribution or solution lost.

Stale bot only exists for aesthetic reasons, to keep issue lists clean and to close issues that maintainers don't want to deal with directly by abstracting away the interaction.

More maintainers should understand that it's OK to just ignore an issue but leave it open.

I'm tempted to make an anti-stale bot that comments on every open Terraform issue to force a human to deal with them. I find new bugs in Terraform providers at least once a week, and invariably they're bot-closed with no resolution. There's no justification for it at all.

Unfortunately, I imagine that GitHub would kill an anti-stale bot even faster than their stale bot kills issues.

I was recently thinking along the same lines. Would definitely use it!

As the maintainer of a moderately popular project on GitHub I'm torn in this. I often get issues where I try to solve the user's problem and think I have answered the question or provided a solution, but don't get any reply from the reporter when asking if it is solved, sometimes for years. I configured Stale Bot with a IMO generous delay so the user has enough time to at least give a short reply if the issue persists. If it does, I'll gladly add a 'pinned' tag to keep Stale Bot away from it. But in the end the bot just does what I'd do by hand anyway.

If it's configured with a short timeout and with preventing further comments, I totally agree. That's rally annoying. But maybe there are circumstances where it's actually useful.

I can't agree more. It's like the CADT model (https://www.jwz.org/doc/cadt.html) but on steroids.