> "actively harmful for the vast majority of use cases" but you've discounted the effect of burnout on maintainers, who are the vast minority of individuals.
No I haven't. I've stated very clearly: closing issue queues will solve for burnout & has less drawbacks than using stalebot. Ignoring open issues is also another very good approach (granted many maintainers find this difficult).
Also in terms of suggesting alternatives, from my original comment:
> Maybe someone could invent a bot that hides ignored issues from maintainers - better maintainer filters.
I'm not aware of a good tool for this, and it would be great if one existed. But the lack of it isn't a good justification for turning to stale bot imo - the trade-offs aren't worthwhile.
> Suggesting that someone turn their issue queue off is a bit presumptive about the possible reasons why your issue was ignored, or why a bot is needed to help keep the issue queue clear enough to be able to easily find out "what's new."
[...] Maybe they really genuinely want the issue queue cleared so that important issues can be given faster attention when they are re-raised because they are important to someone subscribed.
You're presuming that a maintainer knows that the issues being closed are "not important" & also that new issues are somehow more likely to be more important. Stale bot does not have the ability to ascertain the importance of issues - that's what triaging is for & most maintainers don't have the bandwidth to triage faster than stalebot closes. You are invariably closing important issues to make room for users to re-open already closed issues while completely losing context for everyone. That's dysfunctional and net lossy for your project. If you are, as a maintainer, genuinely trying to triage & respond to issues in this system, you're forcing users to generate a higher volume of issues for you & meanwhile losing out on context of previously opened copies of the same thing. It's a net loss of time & efficiency for a maintainer.
Yes it's unfortunate that the alternative is a binary: don't accept issues, or accept having a bunch of open ignored issues, but the only point I'm making here is that stale bot abjectly fails to solve for that gap. It provides no benefit to either of those binary states - it only makes one of them much worse (increases volume of issues while losing context) & additionally alienates reporters of issues. It's a lose lose lose solution for any maintainer that doesn't have bandwidth to triage everything on time (most people).
> Yes it's unfortunate that the alternative is a binary: don't accept issues, or accept having a bunch of open ignored issues,
My whole argument here is the fact that "is there an active maintainer or not" is a continuum, not a binary decision. Any friction we can remove to having an active maintainer remain active, or a new maintainer joining up and becoming active, is a potential boon, drawbacks aside. Stalebot simply removes this friction in the form of "an endless queue of unanswered open issues which you must commit to tackle first." It isn't boundless anymore, only persistent issues will remain open.
If you've ever tackled re-opening a project that has slipped into an unmaintained state for a while you know what I'm talking about. The likelihood that there is anything actionable in an open issue from the distant past actually does decrease as it ages in calendar days and staleness since the last reply. Somebody hanging around waiting for a solution can and likely does take action to ensure their important issue remains open, if it was really important.
Even responding to a stale issue from over a year ago can be a job hazard, as people whose issue was never solved grow more frustrated and irritated about having their problem "bumped" without actually getting solved. It's like poking a bear, maintainers don't want to do it unless they have developed a thick skin of their own, and even then it's not usually a pleasant experience unless you happen to have come with the solution they were asking for in your back pocket.
I would argue that use of stalebot does not increase the volume of issues, even indirectly – the blame goes squarely on users who do not search for their issue before filing a new one. Those users are not irredeemable, but it requires an affirmative commitment to deal with them, and you simply can't decide whether anyone makes that commitment (to spend time dealing with those users) or not. They (the hypothetical maintainer) don't even owe an answer about whether they do.
People begging you to clearly mark your hobby project as unmaintained is another form of social pressure which sometimes pushes people to not publish their work in the future, and that's a shame. You could instead ask if there's a chance that support contracts are going to be sold in the future, but instead you basically "negged" on someone that did something cool for free.
We also wrote a variation on this idea into our governance, because people were asking a lot of questions in Slack that were already addressed by open issues or discussions:
> Bearing in mind that Issues and Discussions are more permanent and searchable than Slack conversations, we can avoid unduly expending finite community resources by searching before asking. If you are not exactly sure how to ask your question or otherwise daunted by the idea of permanence, visitors are always welcome in #project on the (BigCo) Slack.
So...
> Stale bot does not have the ability to ascertain the importance of issues - that's what triaging is for & most maintainers don't have the bandwidth to triage faster than stalebot closes. You are invariably closing important issues to make room for users to re-open already closed issues while completely losing context for everyone. That's dysfunctional and net lossy for your project. If you are, as a maintainer, genuinely trying to triage & respond to issues in this system, you're forcing users to generate a higher volume of issues for you & meanwhile losing out on context of previously opened copies of the same thing. It's a net loss of time & efficiency for a maintainer.
"How many users have filed the same issue" is also a signal you can record and observe, or redirect to the circular file.
It's only a net loss of time and efficiency for that maintainer if they do tangibly exist as a person, and they actually spend that time. This is very much like arguing that technical debt is all wasted time. First, it isn't a waste of time if you haven't spent the time and never do. It's a net gain, "time saved" – until that debt comes back to bite you in the ass. "And that's never a foregone conclusion until it happens, then it was always inevitable that it would."
> most maintainers don't have the bandwidth to triage faster than stalebot closes
This is absolutely true. A problem we can only solve well by having more active maintainers, or less interested users.
I think the root of our disagreement centers around whether a large mass of users who believe some issue is important shall dictate whether the issue is actually important or not within any given context.
If users keep opening the same issue after it's been closed before many times, by a bot or not, then there is obviously some disconnect. Users do not get to decide which way the train drives, the person who does the work is the only one who gets to decide (and the person that merges their PR, I guess)
No I haven't. I've stated very clearly: closing issue queues will solve for burnout & has less drawbacks than using stalebot. Ignoring open issues is also another very good approach (granted many maintainers find this difficult).
Also in terms of suggesting alternatives, from my original comment:
> Maybe someone could invent a bot that hides ignored issues from maintainers - better maintainer filters.
I'm not aware of a good tool for this, and it would be great if one existed. But the lack of it isn't a good justification for turning to stale bot imo - the trade-offs aren't worthwhile.
> Suggesting that someone turn their issue queue off is a bit presumptive about the possible reasons why your issue was ignored, or why a bot is needed to help keep the issue queue clear enough to be able to easily find out "what's new."
[...] Maybe they really genuinely want the issue queue cleared so that important issues can be given faster attention when they are re-raised because they are important to someone subscribed.
You're presuming that a maintainer knows that the issues being closed are "not important" & also that new issues are somehow more likely to be more important. Stale bot does not have the ability to ascertain the importance of issues - that's what triaging is for & most maintainers don't have the bandwidth to triage faster than stalebot closes. You are invariably closing important issues to make room for users to re-open already closed issues while completely losing context for everyone. That's dysfunctional and net lossy for your project. If you are, as a maintainer, genuinely trying to triage & respond to issues in this system, you're forcing users to generate a higher volume of issues for you & meanwhile losing out on context of previously opened copies of the same thing. It's a net loss of time & efficiency for a maintainer.
Yes it's unfortunate that the alternative is a binary: don't accept issues, or accept having a bunch of open ignored issues, but the only point I'm making here is that stale bot abjectly fails to solve for that gap. It provides no benefit to either of those binary states - it only makes one of them much worse (increases volume of issues while losing context) & additionally alienates reporters of issues. It's a lose lose lose solution for any maintainer that doesn't have bandwidth to triage everything on time (most people).