Eh, as a burnt-out maintainer I have to say I can understand the use of stalebot and don't begrudge people using it at all.
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.
> So I think it's good advice that maintainers should use stalebot, because the alternative is a dead project.
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.
Maybe (most likely) this is a problem of GitHub's terminology. For genuine bugs, e.g. here's the repro, the stack trace, the code to replicate it, it happens 100% of the time if you follow these steps, I'd agree that just having it open and in the backlog would be preferable.
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.
> So I think it's good advice that maintainers should use stalebot, because the alternative is a dead project.
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"?
1. Because some issues are still valuable, a well presented bug report that you can immediately act on and is related to parts of the project you want to enhance improves the project.
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.
I think ultimately a lot of that maintainer-consternation is a failure to 1) decide if the project is a 'project' which is meant to be built and maintained by people over time or 2) a source-available reference for others which is actually just meant for personal use. They want the PR and cred of having a popular open-source thing, but dont actually do anything other than putting the source online in terms of fostering it.
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.
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.