5 ms·

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 reasonabl

by yebyen 4y ago

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.

lucideer 4y ago
> 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.
- yebyen 4y ago
  "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! ;)

by yebyen 4y ago

lucideer 4y ago

> 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.

yebyen 4y ago
"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! ;)