4 ms·

Big fan of everything Jeff has put out over the years, having found him back in the day by way of his large catalog of Ansible materials. One request: please d

Big fan of everything Jeff has put out over the years, having found him back in the day by way of his large catalog of Ansible materials. 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.

hu3 4y ago
Agreed. Specially for small and medium activity repos. I would rather be ignored for months than have my Issue closed. Also, issues can help and be helped by others facing similar problems.
- toast0 4y ago
  When running into problems with a project, you can search closed issues too. It's not the default, but it's easy. Maybe there could be a project option to include open and stalebot closed issues.
  - JamesSwift 4y ago
    Yes, that "not the default" behavior is probably half my problem. I cant count how many days I've lost to trying to track down an issue in a project (trying to be a good citizen!), and then ultimately finding that the issue was already reported but closed by stale bot.
deaddabe 4y ago
Worse, stalebot makes it looks like the project has no issues nor known problems. Issues should be closed either with "wontfix" or let open if they detail a real bug that others may stumble upon. In the end, I agree that it takes time to do that, and who am I to dictate how people spend their time. 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.
- ushakov 4y ago
  you can't disable PRs on GitHub, can you?
  - karussell 4y ago
    We need a feature where at least we can review the PR before it is created.
  - khuey 4y ago
    No, but you can have a GitHub Action that automatically closes them. This is what llvm/llvm-project does.
Raed667 4y ago
The only reasonable stale-bot policy for me is when a maintainer asks for more information and the issue creator stops responding.
jeltz 4y ago
Yeah, stale bot is just an awful experience. I would rather not be able to create issues at all.
louwrentius 4y ago
No. You are asking for extra manual labor that the bot was meant to handle.
- lolinder 4y ago
  I'm usually the first to jump in to fight entitlement in open source, but stale bot is, as used, a terrible experience for even the most conscientious would-be contributor. I can't count the number of times that I've been digging around for a solution to a problem and found a GitHub issue that was closed by stale bot with no reply whatsoever. 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.
  - yusefnapora 4y ago
    > don't let people waste their time creating issues in the first place 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#issuecomment-1235398038 https://github.com/dear-github/dear-github/issues/293#issuec...
- plorkyeran 4y ago
  Maintainers doing literally nothing and simply ignoring issues entirely is a better experience than using stale bot.
  - louwrentius 4y ago
    For you. 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.
matkoniecz 4y ago
Stalebot is someone wishing to tell "go away, you are not wanted here" but not having enough honesty to do it openly. 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.
- justin_oaks 4y ago
  It think it'd be OK to use the stalebot if you're more up-front about it's use and why it's being used. A maintainer should be able to make it known up-front "I don't have a lot of time, so I probably won't get around to reading this issue. And I use stalebot which will close issues I'll never get around to dealing with." 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.
  - matkoniecz 4y ago
    I prefer https://github.com/gorhill/uBlock/issues https://github.com/gorhill/uBlock/issues solution where issue creation is simply blocked 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?
  - matkoniecz 4y ago
    > it'd be OK to use the stalebot if you're more up-front about it's use and why it's being used 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).
  - kube-system 4y ago
    I would rather a project that does not respond to issues be honest about it and just leave the issues open. Closing them automatically just to make the number on the tab look nice is the digital equivalent of sweeping dust under the rug.
lesuorac 4y ago
Isn't stalebot just a way of saying no at scale? 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.
- deleted 4y ago
  [deleted]
- dottedmag 4y ago
  No, stalebot is a way to saying "I don't give a damn that you have spent an hour preparing a great bug report lured by the availability of 'New issue' button at the repository" at scale.
  - deleted 4y ago
    [deleted]
toast0 4y ago
I don't like stale bot either, but it does a useful job --- closing issues the repository owner isn't going to fix with less effort and usually less drama for the owner. 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.
- matkoniecz 4y ago
  You can give people permission to triage and close issues.
  - toast0 4y ago
    Sure, but that's more work. Managing people is work. Coordinating about the project is more work. At the end, that person is still on the hook to close issues that aren't going to be worked on, but maybe they want to check first, or maybe they get drawn into an argument about the issue.
    - matkoniecz 4y ago
      In such case letting issues pile up or closing issue tracker altogether is fine if owner is not interested in processing issues. stalebot achieves the same effect, and irritates all people interacting with it
      - kelnos 4y ago
        > In such case letting issues pile up or closing issue tracker altogether is fine if owner is not interested in processing issues. 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.
nonameiguess 4y ago
It's even more frustrating as a basic user scouring web search for the error message you just got and coming across nothing but Github issues that have been going in circles for years with the only engagement being stalebot warning the issue is about to close if no one comments and then someone else commenting "keep open" without any indication whether the developers even read the issue, think it's a real bug or user error, ever plan to do anything about it, care at all, are still even working on the project.
UglyToad 4y ago
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.
- matkoniecz 4y ago
  > 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"? Or let issues pile up? Or have separate garbage dump issue tracker? Done by https://github.com/gorhill/uBlock https://github.com/gorhill/uBlock
  - UglyToad 4y ago
    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. 4. That would just move the problem.
zozbot234 4y ago
Stale issues should be verified against an up-to-date version of the software. If enough time has passed since the issue was first reported and nobody even bothers to check, that's proof enough of the issue being de facto stale and it does no good to engage in denial of this reality.
- lolinder 4y ago
  A lot of people have stale bot set to 1 month or less. Very few open source projects moves fast enough for 1 month to make any difference in replicability.
  - zozbot234 4y ago
    Minor releases may well be issued monthly, and even a minor release might independently fix a reported issue. Additionally, parent poster was not merely complaining about issues being closed too hastily; she was against stalebot as a matter of principle and clearly said so.

hu3 4y ago

Agreed. Specially for small and medium activity repos. I would rather be ignored for months than have my Issue closed. Also, issues can help and be helped by others facing similar problems.

toast0 4y ago
When running into problems with a project, you can search closed issues too. It's not the default, but it's easy. Maybe there could be a project option to include open and stalebot closed issues.
- JamesSwift 4y ago
  Yes, that "not the default" behavior is probably half my problem. I cant count how many days I've lost to trying to track down an issue in a project (trying to be a good citizen!), and then ultimately finding that the issue was already reported but closed by stale bot.

deaddabe 4y ago

Worse, stalebot makes it looks like the project has no issues nor known problems. Issues should be closed either with "wontfix" or let open if they detail a real bug that others may stumble upon. In the end, I agree that it takes time to do that, and who am I to dictate how people spend their time. 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.

ushakov 4y ago
you can't disable PRs on GitHub, can you?
- karussell 4y ago
  We need a feature where at least we can review the PR before it is created.
- khuey 4y ago
  No, but you can have a GitHub Action that automatically closes them. This is what llvm/llvm-project does.

Raed667 4y ago

The only reasonable stale-bot policy for me is when a maintainer asks for more information and the issue creator stops responding.

jeltz 4y ago

Yeah, stale bot is just an awful experience. I would rather not be able to create issues at all.

louwrentius 4y ago

No. You are asking for extra manual labor that the bot was meant to handle.

lolinder 4y ago
I'm usually the first to jump in to fight entitlement in open source, but stale bot is, as used, a terrible experience for even the most conscientious would-be contributor. I can't count the number of times that I've been digging around for a solution to a problem and found a GitHub issue that was closed by stale bot with no reply whatsoever. 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.
- yusefnapora 4y ago
  > don't let people waste their time creating issues in the first place 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#issuecomment-1235398038 https://github.com/dear-github/dear-github/issues/293#issuec...
plorkyeran 4y ago
Maintainers doing literally nothing and simply ignoring issues entirely is a better experience than using stale bot.
- louwrentius 4y ago
  For you. 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.

matkoniecz 4y ago

Stalebot is someone wishing to tell "go away, you are not wanted here" but not having enough honesty to do it openly. 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.

justin_oaks 4y ago
It think it'd be OK to use the stalebot if you're more up-front about it's use and why it's being used. A maintainer should be able to make it known up-front "I don't have a lot of time, so I probably won't get around to reading this issue. And I use stalebot which will close issues I'll never get around to dealing with." 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.
- matkoniecz 4y ago
  I prefer https://github.com/gorhill/uBlock/issues https://github.com/gorhill/uBlock/issues solution where issue creation is simply blocked 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?
- matkoniecz 4y ago
  > it'd be OK to use the stalebot if you're more up-front about it's use and why it's being used 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).
- kube-system 4y ago
  I would rather a project that does not respond to issues be honest about it and just leave the issues open. Closing them automatically just to make the number on the tab look nice is the digital equivalent of sweeping dust under the rug.

lesuorac 4y ago

Isn't stalebot just a way of saying no at scale? 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.

deleted 4y ago
[deleted]
dottedmag 4y ago
No, stalebot is a way to saying "I don't give a damn that you have spent an hour preparing a great bug report lured by the availability of 'New issue' button at the repository" at scale.
- deleted 4y ago
  [deleted]

toast0 4y ago

I don't like stale bot either, but it does a useful job --- closing issues the repository owner isn't going to fix with less effort and usually less drama for the owner. 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.

matkoniecz 4y ago
You can give people permission to triage and close issues.
- toast0 4y ago
  Sure, but that's more work. Managing people is work. Coordinating about the project is more work. At the end, that person is still on the hook to close issues that aren't going to be worked on, but maybe they want to check first, or maybe they get drawn into an argument about the issue.
  - matkoniecz 4y ago
    In such case letting issues pile up or closing issue tracker altogether is fine if owner is not interested in processing issues. stalebot achieves the same effect, and irritates all people interacting with it
    - kelnos 4y ago
      > In such case letting issues pile up or closing issue tracker altogether is fine if owner is not interested in processing issues. 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.

nonameiguess 4y ago

It's even more frustrating as a basic user scouring web search for the error message you just got and coming across nothing but Github issues that have been going in circles for years with the only engagement being stalebot warning the issue is about to close if no one comments and then someone else commenting "keep open" without any indication whether the developers even read the issue, think it's a real bug or user error, ever plan to do anything about it, care at all, are still even working on the project.

UglyToad 4y ago

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.

matkoniecz 4y ago
> 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"? Or let issues pile up? Or have separate garbage dump issue tracker? Done by https://github.com/gorhill/uBlock https://github.com/gorhill/uBlock
- UglyToad 4y ago
  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. 4. That would just move the problem.

zozbot234 4y ago

Stale issues should be verified against an up-to-date version of the software. If enough time has passed since the issue was first reported and nobody even bothers to check, that's proof enough of the issue being de facto stale and it does no good to engage in denial of this reality.

lolinder 4y ago
A lot of people have stale bot set to 1 month or less. Very few open source projects moves fast enough for 1 month to make any difference in replicability.
- zozbot234 4y ago
  Minor releases may well be issued monthly, and even a minor release might independently fix a reported issue. Additionally, parent poster was not merely complaining about issues being closed too hastily; she was against stalebot as a matter of principle and clearly said so.