Maintainers are great, and working open source projects are good, but not every project has an active maintainer, and it's my opinion that practically no one in Open Source signed up to be a "repo owner", unless they've gone to the trouble of developing some kind of governance structure to signal that they should be counted upon for support. That signal is an affirmative signal though, it's not implied.
If you don't get a reply, and a robot closed your inquiry without comment then my guy, it seems that the signal has been sent clearly and received! If you disagree the fork button is in the upper right hand corner, you are the maintainer now!
I don't mean this to be disrespectful, but there are a lot of open source projects supporting companies and the companies often don't contribute back in any way. So while I appreciate the PR, and I'm going to be as polite as possible before I close it, not everyone has time for that, and nobody owes it.
I'm not the commenter, but I think you're misinterpreting the intent of the comment (or at the very least I interpreted it differently).
> I expect at least some triaging from the maintainer before the stalebot comes in
I didn't read this as "maintainers should always triage", I read this as "stalebot shouldn't axe issues unless maintainers are triaging" (see my original comment for why). One could reword the above comment for extra clarity/emphasis as:
> I expect that before stalebot comes in [it should check whether] some triaging from the maintainer has been done]
i.e. I don't think @bouke was shitting on maintainers, just on stale bot as a product.
Of course maintainers should be under no obligation to do anything whatsoever: none of that is particularly relevant here when we're just discussing whether stale bot adds value.
(I see Jeff has replied here too but also completely skipped over addressing criticisms of stale bot & focusing on the strawman of maintainer responsibility - which noone is debating)
I avoid stalebot for the reason you describe, because I want a maintainer to be reading and triaging issues, and I am in a job description where I can reasonably anticipate to be that person at least 40% of the time, even if I may not be coming through often enough (with a high batting average.) I'm really lucky to work for a company that can prioritize this type of interaction!
But when maintainers are overextended or nobody is able to commit that way, I see the value of stalebot. I spent a year closing 400 issues by hand for a popular legacy tool that we were actively telling folks not to use, nearly already on the day I started working on it. They were all so grateful to have someone reading over their issue and for the community goodwill it created, it was definitely worth it – for me. Different value systems and judgements may not make it so valuable. To be as direct as possible, I have 0 information on whether any of those grateful people were ever converted into paying customers of our company (and I like it that way.)
Was it worth it in engineering dollars, or if you measured the output of the time spent reading each issue in terms of how it influenced directly on LOC output from my brain to my keyboard? Definitely not (at least not yet, short-term.) We kept the lights on, and the exit door illuminated, to demonstrate a commitment to support. In service of governance and long-term stability guarantees!
Would we have gotten people off the boat faster if we had gone ahead and decided to pre-emptively close every issue that was not likely to get attended to, based on engineering effort/$$ calculations with low information about each issue? Very much possible. Some people may have also gotten alarmed and decided to swim from there, rather than trust our lifeboats to take them somewhere safer. See how stalebot provides value in this case, if "abandon ship" is the message you want to send ;)
I may have made your (their) point even better for you, my point is simply different value judgements based on different calculus.
> See how stalebot provides value in this case, if "abandon ship" is the message you want to send ;)
Yes, that's great. Stalebot provides value for a project you want to kill. That's not what people use it for mostly though. If that's its purpose call it killbot.
The point is not that stalebot is useless - I even said it sounds useful specifically for Jeff's use case. The point is that stale bot is actively harmful for the vast majority of uses in the wild: having a few rare cases of value doesn't change that.
"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.
This effect must not be understated, sustainability is a primary concern, as you'll see at the top of this thread, I started with "not every project has an active maintainer" - this is not always a state that arises in a perfect vacuum or even over a well-defined span of time, when an author loses interest in their creation and stops contributing to it. It is a terminal state in a state diagram with many open loops, and perhaps one to be avoided if you're keen on maintainers triaging issues! But also sometimes unavoidable.
If the active maintainers are all chased away by hungry users, clamoring for architectural changes without a full understanding of the project and how it's designed to work, then there is value in a bot chasing away the people who are just window shopping for something completely else than what you sold them, or even what else you had planned in your as-yet unexpressed vision for the future.
Spending the spoons required for an interaction is not without a compounding cost in all cases either. If your response is not simply accepted, or it's actually reiterating just what you already knew the user didn't want to hear, well... you've now entered the "bargaining" or "negotiating" phase of issue triage, and the next step is... well, another step
I negotiate with those users because they usually have valuable insights hidden inside of their pain! Our lead maintainers would spend time doing the same, but the more time they spend on that, the less time they have to spend on writing code and actually developing the software.
See how this model basically hinges on adding more people to the maintainers team as the user base scales up? And to the point, sacrificing some of their labor in service of triage role activities? If you are a single maintainer for many repos, you desperately need to avoid becoming a customer service bot for your non-paying customer-users. Spending time servicing those users can result in negative feedback loops where people expect more attention just because you gave it once. This has not been my experience most of the time, but...
...And that's not to say the issue queue won't be used for something else... but... maybe just your issue didn't make the cut. And that's not an affirmative value judgement – it just means maybe it did not make the cut for that maintainer's roadmap, who owns the queue, even if such person currently exists. Like I said, nobody signs up as "repo owner" when they publish their work, but it is their queue.
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."
It really might not actually be that they ignored your PR/report just because they want to kill the project? 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.
If you've gone to all the trouble to track down 16 issues that provided details about the same report when they were all closed then you know it's possible, they aren't inaccessible just because they've been closed; it's just a bit frustrating – maybe also notice an important indicator of the volume over quality of the average issue submissions that 15 people didn't search well enough to find a closed issue that was a dupe of their issue! Did they even search before posting at all?
Anyway, if you're doing all that, then bottom line you should absolutely be a maintainer. Add yourself to the MAINTAINERS file and then go ahead and turn that stalebot off! ;)
> "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)
This, basically. And for probably 80% of issues, a maintainer might actually read the notification, but to click through, leave some sort of intelligent / honest reply, and either click close or reply and move on takes infinitely more time (when you're dealing with 100+ new issues and PRs a day) than not responding and moving to the next one.
A non-response does signal one thing—the maintainer doesn't seem interested enough to touch the issue. Fork the project or maintain a patch separately if you need to, and move on.
If you don't get a reply, and a robot closed your inquiry without comment then my guy, it seems that the signal has been sent clearly and received! If you disagree the fork button is in the upper right hand corner, you are the maintainer now!
I don't mean this to be disrespectful, but there are a lot of open source projects supporting companies and the companies often don't contribute back in any way. So while I appreciate the PR, and I'm going to be as polite as possible before I close it, not everyone has time for that, and nobody owes it.