4 ms·

> I also enabled the GitHub Stale Bot on most of my repos, and let me tell ya—for a lot of people that seems to be a hot-button topic. and for good reason. Rea

> I also enabled the GitHub Stale Bot on most of my repos, and let me tell ya—for a lot of people that seems to be a hot-button topic. and for good reason. Reasons not stated nor addressed in this article, which I find concerning. > Despite how much some people detest the stale bot, it—along with a more easygoing attitude towards my projects—is the best burnout prevention measure I've personally taken. That's great: individual mental-health is more important. But disabling issue creation on all of your repos would've had a similar effect on burnout prevention, with all of the same benefits as stalebot & less of the drawbacks (no false sense of contribution created with users, no bridges built to be burnt). > I enabled the Stale Bot because it was an admission of this fact: Unless I specifically mark an issue as a bug or being 'planned' in my roadmap, it's just not that important to me. That's great in theory, and Jeff being a prolific & conscientious engineer, may actually work reasonably ok in practice for him. But it doesn't work this way for the vast majority of projects. For most, enabling stalebot is a measure to stave off disorganisation within the project, in which case they're not marking issues in a roadmap in any kind of timely/efficient manner nor really organising their issue queues well at all (as Jeff states here that he already is). Most issues that stalebot closes haven't even been looked at by maintainers. If you don't have the time to look at issues, ignore them. I do get that psychologically this is tricky as many chase a "Zero Inbox" type of approach to issue queue management, but take a look at any mature well-organised open source project and you'll see unaddressed issues that are years and years old. Maybe someone could invent a bot that hides ignored issues from maintainers - better maintainer filters. But as a user, I want to find those open issues & read the workarounds. I want to submit PRs to address them without having to keep track of 16 different issues opened on the same persistent problem that keeps getting closed stale. This tool might work for Jeff but if it does he's in a tiny minority & it's irresponsible to advocate its use for everyone without addressing the well-known criticisms at all.

bouke 4y ago
This is exactly my issue with stalebot and I think it is a great disservice to the community. Closing issues without a maintainer looking at the issue is bad. I expect at least some triaging from the maintainer before the stalebot comes in and swipes the issue under the carpet.
- yebyen 4y ago
  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.
  - geerlingguy 4y ago
    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.
  - lucideer 4y ago
    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)

bouke 4y ago

This is exactly my issue with stalebot and I think it is a great disservice to the community. Closing issues without a maintainer looking at the issue is bad. I expect at least some triaging from the maintainer before the stalebot comes in and swipes the issue under the carpet.

yebyen 4y ago
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.
- geerlingguy 4y ago
  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.
- lucideer 4y ago
  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)