What an odd point of view. It doesn't sound like you respect your users at all.
People are weirdly entitled and feel like you really, really must fix the bug.
Often with no real actual datapoints or way to reproduce.
Still, auto-closing bots are annoying. But I see why people might want them
Unfortunately, most maintainers just don't have the time to handhold 5-10 users per day for there projects, not when that means they'd not have time for other things, like family, recreation, etc.
We have extremely limited time, it's an impossible task to manually handle the deluge of issues.
At least I'm not expecting this of anyone maintaining any Open Source, popular or not. (Thanks for your great Ansible work, BTW!).
But how is auto-closing after X days a solution to "manually handling a deluge of issues"? Would, for example, it not be a much simpler and logical workflow to read those issues which you will handle manually and ignore all the rest? Why do they need to be closed?
Likewise, why do they need to be open? Closed or open is just a state anyway, since the issue is still there.
The fact that it's closed at least makes it clear that we won't deal with that issue (why we won't is explained in the template when the user creates the issue). If it stays open, we also won't dealt with it, but it will give the wrong impression that we might, some day.
Closing does not send the same signal as flagging, tagging or simply ignoring. Closing implies finality. It implies it's gone; and in fact it will be gone from most searches.
Edit: to be clear: I don't mind someone closing my PR with a short explanation. Say "thanks for your Makefile, but since we have a lot of developers on Windows, we fear that switching to makefiles for our automation only adds to confusion. So I am closing this". this is very different from a bot coming in and closing such a PR. The latter signals to me "we are so overwhelmed that your help is not welcome so we sent a bot to keep you away from us. No-one even looked at the work you did for us. Now shut up"
Tagging something as "backlog", "someday" or "low-prio" is a far different signal than closed.
Maybe the root of the entire problem lies in the github-issues being too simple for large open source workflows. A lack or additional statuses, a lack of dimensions maybe. open/closed is one-dimensional, tags add a second dimension, and swimlanes when using GH projects a third. Maybe we need "read"/"ignored", or "team assignments" or such as additional dimension. Or maybe we need worked out templates for tagging-structures and workflows? (without it becoming another jira mess)
Because clearly there is a need for workflows on top of Github, as can be seen by people pulling in bots that clearly piss off a lot of other people.
I think that's a pretty harsh take. At the end of the day issue trackers are a tool for maintainers to help manage the project/codebase and the details are largely up to them. Im sure some maintainers also use it as a tool for communicating with users, but I don't think it should be compulsory. At the same time, if I as a user of a project add a bug then I do that as a favour to the maintainer. I don't think you should necessarily expect something back from the maintainer (assuming we're talking about open source here, not some payed service with an SLA etc.)
I’m not getting angry, per se, but more disappointed and concerned that the project might not have enough resources to make me feel comfortable using it in the way I intended. (The one I’m thinking of was a cross-cloud app that obviously got more love on AWS than GCP. I got the feeling from the staled bugs that GCP was the “red-headed stepchild”, so we phased that app out after the POC.)
I like the “bug reports are signals, not tasks” idea, though. As a user, I’ll keep that in mind and see if that helps change my gut reaction to the stalebot.
The problem is those bugs don't affect the right people to have them care about fixing them, so they'll just sit there open forever.
At least the stale bot would signal "as a community of developers, this issue doesn't have enough interest or priority to get fixed".
... why should respect be something that needs to scale ? it's fine to admit that this kind of respect itself does not scale when you're a single OSS maintainer.
This attitude is really the crux of it. Someone is working on a project, and has to argue - endlessly - with users who demand "respect" but don't contribute.
Quick tip to users:
The maintainers and bug tracker is generally not a support / training channel.
The quickest way to get respect is to help out.
There's a far cry between disrespect and avoidance/minimization of challenging social interaction.