One request: please dont advocate for stale bot :( I understand the tension between maintainers sanity and developers sanity, but there has to be a better way. It is absolutely _maddening_ as the consumer to interact with a stale-bot enabled repository. Please, just manually close the issues as 'wontfix' and link to this blog post instead.
Maybe the best solution would be to completly disable issues and PRs on Github. Still better than having to deal with stalebot. At least you know what to expect: external solicitation is not welcomed.
When I started my project, I had the attitude that I'd be better than all these other maintainers. They flaked out but I'm just that much better that I'd never let the project wither.
But over time the backlog of things you're just not going to get to, or don't have enough information but you don't have time or motivation to go through composing a reply, begins to cause a genuine psychic pain. To the point you can't even open the repository because it's a reminder of all the ways you're failing.
So I think it's good advice that maintainers should use stalebot, because the alternative is a dead project.
Sure, it sucks that the issue you put time and effort into gets memory-holed but you're owed nothing for the time, as TFA says, fork it.
Edit: Even manually closing as wontfix is that much more work, you're asking for every issue in the backlog the maintainer does the emotional work of deciding that the issue is unsalvageable from their perspective and takes a manual action that will potentially get people mad at them and now they have to deal with being flamed. Closed issues are still searchable and preserved in the issue backlog, they don't disappear forever.
Why not just close issue tracker? Or autoclose everything immediately rather than remind people weeks/months later about their bug, just to discover that they got "pranked"?
Or let issues pile up? Or have separate garbage dump issue tracker? Done by https://github.com/gorhill/uBlock
2. As above, you want to work on some of the valuable issues of interest to you as a maintainer, but if you glance at one and think "that looks like a lot of work" or "that's an x-y problem" or "I'd need to go back and forth 5 times to get enough information to action that" then you can just ignore it and have the bot close it if you never get the motivation, time or energy to go back to it.
3. As I mentioned in my comment, having an ever growing backlog has a genuine detrimental emotional impact that directly causes maintainer burnout.
4. That would just move the problem.
This doesn't follow at all for me. What stalebot causes is a project that superficially seems to be in great shape, having only a smaller number of fairly recent bugs open.
Whereas in reality it's a project with tons of known bugs that just get sweeped under the proverbial rug to make the bug list appear deceivingly clean. The passage of time doesn't make a bug go away, it's still a bug in the project.
The conflict arises because a bug database serves multiple purposes. Yes, it's a To-Do list for engineering. In that context, not everything can be done now so it might be understandable to close them. But the same can be achieved by lowering the priority which puts it at the bottom of the To-Do list.
But the other purpose of a bug db, a more important one, is that it is the repository of knowledge of all known problems with the project. It allows consumers of the project to understand what isn't working and to see where the quality trend is going over time. Yes, this could also be achieved with a document on Known Issues explaining the problems and ideally the reason they don't get fixed. But a project that's closing bugs automatically with a bot I bet isn't putting the effort into such documentation either.
I never close any bugs due to time. If they accumulate, so be it. It's a honest representation of the state of the project to would-be users. Eventually I get to it, might be many years later, but the bug was still there. When I close the bug intentionally it's because it's no longer an issue.
The problem is those make up maybe at a generous estimate, 10-15% of issues in a projects backlog. In the interests of full disclosure here's mine (I don't use stalebot) https://github.com/UglyToad/PdfPig/issues?page=1&q=is%3Aissu.... As you can see from the backlog I close almost nothing. This was a deliberate choice to avoid closing things until the fix was confirmed by the reporter.
But equally that's the first time I've opened the repository in a couple of months and the amount of angst and dread I feel just from the size of that list means I'll probably find yet another excuse not to do anything on it this coming month.
Discussions on this topic feel a lot like "technical solutions to social problems"; by which I mean "well in the ideal world a perfectly logical person would do x, y, z so the system should reflect that". And while a stalebot is the archetypal technical solution to a social problem it at least works with how maintainers work. Sometimes in life you want to ignore a problem and have it go away. When you can't do that, e.g. government bureaucracy, work stuff, social obligations, that's where stress comes from. And asking volunteer maintainers to add a whole new source of stress in their life falls apart when people get busy, or their life circumstances change, or they get ill or tired or whatever.
Yes, in a perfect world the issue backlog would be sacrosanct and perfectly groomed/prioritized. But we're just fleshy sacks of chemicals and we're not perfect. Unrealistic expectations from users are the cause of maintainer burnout.
Because GitHub closed issues are still viewable and searchable (I'd guess most people search it through a search engine not the terrible inbuilt search) I'd disagree that they're deceiving users somehow.
I understand this, and I too put my stuff online a lot of times just to build up my street cred, but if thats the only purpose then you need to make that clear in your communication and how you manage the project. If you _are_ intending the thing to grow and be used you need to do that intentionally. The two biggest offenders for that tend to be 1) not moving to an organization account and 2) not fostering contributors to lessen the individual load. Again, because the project is actually a personal project not intended to be touched by others (but hey if you would use it and star it that would be great because then its even better PR for me!).
So yes, I understand its a tough spot but in many ways I view it as self-inflicted and think communication (both explicit and implicit) goes a long, _long_ way toward setting expectations.
It is fine to disable issue tracker if you do not want people to file issues.
It is fine to reject feature requests.
But stale-bot is the most annoying way of doing this.
Maybe you could provide that information in the GitHub issue template.
That said, this would be a more ideal situation. I understand that open source maintainers are not under any responsibility to be helpful to contributors... but the world would be better off if they were.
In this case users directed to garbage dump issue tracker but it also can be skipped.
Main problem with stalebot is wasting time on proper issue which is then closed without ever being read by human.
Maybe compare it to place offering users to fill poll or write feedback form? And then dumping them straight into paper shredder?
Maybe simply do not encourage users to fill feedback forms if you will shred all of them anyway?
I would be probably OK if that would be clearly stated in CONTRIBUTING.MD file (and/or in pinned issue or other place seen by issue reporter who bothered to do minimal research).
I would rather be ignored for months than have my Issue closed. Also, issues can help and be helped by others facing similar problems.
If you take an affirmative action to close a bug, that's an opportunity for the reporter to argue. If stale bot does it, you can argue with stale bot, and stale bot doesn't care. Reopening it because it's still broken and you still care is a signal of some sort.
stalebot achieves the same effect, and irritates all people interacting with it
That's so black-and-white. Perhaps the owner is interested in processing issues, but not all of them. That seems to be the more common case. Closing the issue tracker would not be useful. And letting issues pile up can be stressful for a maintainer.
> stalebot achieves the same effect
No it doesn't. It allows a maintainer to avoid having to manage issues that they probably won't get to, while allowing them to manage the issues they are actively working on, or plan to work on.
and irritates all people interacting with it
Tough shit. Random people on the internet are not entitled to any particular level of support, or issue resolution policy from the maintainer.
Oh, definitely. I am not a God-Emperor of issue tracking.
And projects adding stale-bot are unlikely to actually need my support/issues/donations/anything else.
Though I hope that projects will find other less hostile solutions.
The kind of thought that goes into choosing GitHub for projects' bugtrackers is about the same level of thought that went into the decisions of anyone who was using Internet Explorer 10 years ago: they didn't think about it a lot, nor did they particularly care—they just picked it because it was there.
Like if nobody resolved the issue in the past x months then they're probably not going to resolve it in the future either so close it to remove noise.
You are asking for extra manual labor that the bot was meant to handle.
Leaving the issue open until someone has a chance to actually look at it isn't extra manual work, its common courtesy from a project that is soliciting feedback. If you're not interested in feedback, don't let people waste their time creating issues in the first place.
If stale bot would by default only close an issue if the last reply was from a maintainer, that would be a different matter.
But then you don't get to use issues to track things that you personally care about. It would be nice if there were a way to enable issue creation by the repo owner / maintainers, but disallow it for the public at large. Especially now that "discussions" are a thing, which gives a place for people to comment without implicitly requesting work from the maintainer.
Apparently this is sort of possible[1] by setting `blank_issues_enabled: false`, so that you can only create issues from the Project page.
[1]: https://github.com/dear-github/dear-github/issues/293#issuec...
For them, having all those issues closed helps filtering the clutter. Or whatever reason they have for running it, maybe it's the only way that they can still maintain some desire to work on the project and not abandon it. A small price to pay then I guess.