34 ms·

GitHub stale bot considered harmful

338 points by als0 5y ago

blincoln 5y ago
I ran into this a few weeks ago with a PR I submitted. Auto-closed as stale after ten days after no interaction with a human. As someone who's been on both sides of writing and using software, this is not a good way to encourage people to use and contribute to a project.
joshxyz 5y ago
Got pissed off on it on ioredis repo. Project touts its low open issue count but most of its closed issues are bugs unaddressed by the maintainers. Fucking stupid.
throwaway439893 5y ago
> I’m not sure what motivates maintainers to install this on their repository If you knew why it was being used, you might not "consider it harmful"
- MereInterest 5y ago
  Please interpret the author's words charitably. In the context of the rest of the article, the opening sentence doesn't imply ignorance of the reasons why it is used, but rather understanding those reasons and finding them insufficient.
selfhoster11 5y ago
Hell yes. If you have an open issue, you have an issue. It doesn't disappear because you wish it away with a bot. Ticket overload may be a problem, but stale bots do not solve it.
- ajsnigrutin 5y ago
  This depends There might be an issue like "I get an error message, and then the software crashes!", you ask "what error message? What version? What does the log say?", and you never get a response, and the issues gets burried and forgotten.
  - Snetry 5y ago
    Yes, but a stale bot is not going to stop those from appearing and will close issues with steps to reproduce and tracebacks
    - darkwater 5y ago
      Exactly. If you want to improve quality of reports, GH now let's projects even ask some questions before opening an issue, to redirect users to the proper channel. And if the proper channel is an issue, there is the ISSUE.md template that has been working for several years already now.
      - dhaavi 5y ago
        I only know the issue templates with the chooser. Can you point me to the feature you referred to with „GH now let's projects even ask some questions before opening an issue“?
        darkwater 5y ago
        We are probably talking about the same feature. What I meant was this kind of page https://github.com/home-assistant/core/issues/new/choose https://github.com/home-assistant/core/issues/new/choose
        imtringued 5y ago
        That looks fantastic.
        dhaavi 5y ago
        Ok. Thanks. That’s how we use it too. I guess the question thing got me confused.
        darkwater 5y ago
        Yeah sorry for that, it's a multichoice page which inherently asks you a "what are you trying to do?" question.
moffkalast 5y ago
I am Jack's complete lack of surprise
chrismorgan 5y ago
A previous thread on an article about stale bots: https://news.ycombinator.com/item?id=25821092 https://news.ycombinator.com/item?id=25821092 Closing issues automatically is bad enough—I’ve long complained about the stale bot, seeking for it to be discontinued with prejudice as it’s only harmful, literally never helpful (as an issue tracker, that is—it may possibly help maintainers’ mental state because it can facilitate more effective ostrich imitation than just ignoring the issues as they pile up). Then there’s the GitHub action that has largely supplanted it (and which is what’s actually in the screenshot), which doesn’t just close, but locks (no idea if it’s configurable). A bot to close issues I can understand, people have been copying this misfeature from other sorts of trackers (… where it’s also normally a misfeature) for a long time. But making it lock issues is an even stupider idea than closing, amplifying the problems of closing even further for no reason that I can imagine, and I am baffled that that ever got implemented at all. I think it’s indefensible, but I’m rather curious to hear a defence of it.
- oauea 5y ago
  The best part is when the developers then close & lock your new issues as duplicates. No discussion allowed, I guess.
  - pas 5y ago
    stay calm & fork
  - deleted 5y ago
    [deleted]
  - joshxyz 5y ago
    This is borderline absurd i cant comprehendo anymore hahahah fuck
- nyuszika7h 5y ago
  I agree, this is incredibly frustrating. Sometimes it's hard enough to even get developers to reopen issues closed for inactivity, if they're locked it's even worse. I often don't even bother trying to open a new issue for the same thing unless it's critical, I just leave in frustration.
quadrifoliate 5y ago
In my experience, these auto-closing bots are the natural result of software development workflows that treat issues as tasks to be closed, rather than a data point that a user is experiencing a problem of some kind (maybe they are doing things wrong, expecting something the project doesn't provide, or triggering a real problem – the exact cause is immaterial). This treatment of issue-as-a-task is made worse by corporate micromanagement frameworks like Agile, which encourage metrics on how many of these issues-as-tasks are closed, which leads to ill-advised features like this that close them automatically because "Duh, no one said anything in 30 days". If I were to design this myself, I would argue that the correct way to treat an issue is not to have it have a closed or open state at all. If the issue spawns a task or related tasks, you can close those. Or you can provide feedback on the issue that states that it is invalid. The user has already experienced a problem or wants a feature, there is no value in putting a red label that indicates "I'm done with this, please go away". It unnecessarily invalidates the experience of users who have their provided valuable time to report something to your software project. I think this is similar to the approach used by forums like Discourse, where a thread about a problem will usually not be closed or locked, but will just age out of current discussion if nobody brings it up.
- c7DJTLrn 5y ago
  Yep. GitHub Issues is not a scrum board and shouldn't be treated as such. It's for consumers to discuss with authors and other consumers.
  - pc86 5y ago
    If its point is really consumer discussion with authors (I don't think it is) then Issues is a pretty terrible name for it. Given the overall quality of GitHub in literally every other aspect of the product, I find that unlikely.
    - npteljes 5y ago
      Yes, I think this is it. It all might have been started as "bugs" or "Issues" but over time, the functionality was extended to have feature requests, different discussions, etc. I don't have an alternative name for this, Notes maybe? But Issues sounds more severe than what it usually is.
cedws 5y ago
Completely agree with Drew here. Nothing pisses me off more than seeing an issue I care about or raised closed because it was "inactive". Just why? If issues went away by themselves we'd all be out of jobs. All these bots do is piss off the consumers and make your life harder by losing discussions. They also waste the time of those who put a lot of effort into their report to be helpful, encouraging lazy spam issues to be created in their place. GitHub should remove this disgraceful bot.
- fireflash38 5y ago
  It also makes it so that you get a ton of effectively spam comments on an issue to keep it 'active'. That said, I guess it's got some value in that it forces someone to become a squeaky wheel by bumping an issue they want to get fixed?
  - gaius_baltar 5y ago
    I then wonder if somebody has a bumpbot now, just to prevent these issues from being closed by stalebot. :)
    - techdragon 5y ago
      I was going to ... In fact I just did a bunch of research for half an hour. I picked a language, hosting, UI tools, looked up the API calls and worked out how to do most of the mechanical process behind the scenes. Despite being a decent idea and a product I'd 100% use myself, I'm not sure I should do any more work on the idea due to GitHub's Acceptable Use Policy... > 10. User Protection > You must not engage in activity that significantly harms other users. We will resolve disputes in favor of protecting users as a whole. I can see a lot of arguments that GitHub could use to label any kind of automatic "bumpbot" bot/tool/service in widespread use as violating this clause. If I was more confident it wouldn't get ban-hammered and shutdown, I'd pop back open that folder of notes and get at it.
    - remram 5y ago
      I was considering making a browser plugin to have a one-click button to comment "this issue is not going away by itself, please read it before you decide it's stale" or similar. Now that ddevault wrote this it might be a good resource to put in there. Making a completely automated bot certainly falls short of GitHub's acceptable use policy.
Longhanks 5y ago
“Considered Harmful” Essays Considered Harmful https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html
vemv 5y ago
Devil's advocate: some projects are extremely open-ended and will always have issues, hundreds of them. Bugs will be a permanent condition of the project so some bugs might be not deemed relevant, ever. Auto-closing helps here. If nobody is attending a given issue, definitionally it doesn't have an economic value: nobody deemed the issue/task worth solving OR paying for it. It might be annoying, but not sufficiently annoying to take action. It doesn't block your business, workflow, productivity etc; if it was, you'd be personally involved in solving the issue in some or other way.
- MereInterest 5y ago
  > Devil's advocate: some projects are extremely open-ended and will always have issues, hundreds of them. Open-ended projects may have design/feature request issues, but those should be distinct from bug reports. And those design/feature request issues are exactly the kind that most require human interaction, to decide whether something should be part of the program. > Bugs will be a permanent condition of the project Bugs are a fact of life for any developing software. Any particular bug is not. Closing an issue is a statement about that particular bug being fixed. Auto-closing an issue due to staleness is a lie that the bug has been fixed. That said, if there's an automated reproducible test case for the bug, then it could be closed when that reproducible test case passes. If a seemingly unrelated change resolves the issue, and that can be verified, then it would be acceptable to auto-close the issue as a result. > so some bugs might be not deemed relevant, ever. Auto-closing helps here. There's a big difference between "not deemed relevant" and "deemed not relevant". The former is when you have an issue that sits open for some time, and sure, that might not be relevant right now, but could be important later. The latter is an active decision that something is irrelevant and never will be relevant. That's the message received from an issue being closed, which is a far more aggressive message. Auto-closing delivers this aggressive message, throwing away the work somebody has done in reporting the issue, without even so much as an acknowledgement. > if it was, you'd be personally involved in solving the issue in some or other way. Reporting an issue is being personally involved in solving it. Writing a solid issue, clearly documenting how to reproduce, expected behavior, observed behavior, why the expected behavior would be closer aligned with other behavior in the program, etc, takes time and effort.
laurent123456 5y ago
I rely a lot on stale bot actually, simply because I don't like closing issues. When you do that, users sometimes get upset and you have to explain that this is not a bug, or it's a duplicate of another bug, or that we use GitHub issues as a bug tracker, not for support, etc. Then the user might argue that it's not exactly the same bug, or that we should leave it open for reason x or y. It's a time consuming process that needs to be repeated very often when you manually close bugs. And it's mostly worthless because we know what we're doing - we know what will be worked on, what will be ignored. We just tag the issues that we'll work on and Stale Bot will skip these. So now I don't close anything anymore and let users get mad at Stale Bot instead. It's a bit weird but the end result is the same.
- fistynuts 5y ago
  What an odd point of view. It doesn't sound like you respect your users at all.
  - shp0ngle 5y ago
    If you have even a mildly successful github repository, you will understand. People are weirdly entitled and feel like you really, really must fix the bug. Often with no real actual datapoints or way to reproduce. Still, auto-closing bots are annoying. But I see why people might want them
    - geerlingguy 5y ago
      And there are a ton of non-bug issues that people feel entitled to your time (as a maintainer) to respond to and help them. Often for many, many comments. Unfortunately, most maintainers just don't have the time to handhold 5-10 users per day for there projects, not when that means they'd not have time for other things, like family, recreation, etc. We have extremely limited time, it's an impossible task to manually handle the deluge of issues.
      - berkes 5y ago
spondyl 5y ago
The CADT model seems relevant here: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
- mikl 5y ago
  You can’t link jwz.org from here, he’s set up referrer detection so you get an image of a testicle in an egg holder if you follow a link from here.
  - techdragon 5y ago
    Worked for me in Safari on macOS. (I'm not sure if that's because of Safari or jwz though)
fabian2k 5y ago
While I think that closing issues after a certain time is really problematic, there is an inherent problem with a certain subset of stale issues. The most problematic part is that the older issues become irrelevant over time, in part because the system changed too much and they don't apply anymore or because the people originally asking aren't interested anymore in the answer. If you just accumulate old issues it becomes hard to find still relevant issues in this whole pile. I don't think closing based on time is always a bad idea, but you should have a good mechanism to save issues that are relevant from the bot. In the end you always need some minimal triage on issues to keep them usable.
TrianguloY 5y ago
Also, on GitHub when you want to search an issue it filters by open only (you need to remove it manually). This brings on a lot of duplicated issues, so in some cases it increases the mantainers job.
majkinetor 5y ago
Nonsense. You can always browse closed issues. The fact that issue is closed means absolutely nothing to the promoted methodology.
- rudian 5y ago
  What’s the point of having an open/closed status if an unsolved bug is now “closed”? You might as well close Issues and use Discussions instead.
  - majkinetor 5y ago
    The point is that visibility state of the ticket is irrelevant and not connected to the resolving state. The point of closed bug is one among the not confirmed, not affecting too many users, hard to fix, unable to fix, no time to fix, no interest in fixing it, higher priority fixes piled up etc... Staleness is also meaningful on its own. Let me repeat - Nonsence.
    - rudian 5y ago
      > Staleness is also meaningful on its own. It absolutely isn’t. Look at Mozilla’s bugzilla instead: You’ll find plenty of bugs open for years and eventually fixed. Plus, stale bots don’t take Reactions into consideration. Spend a week on a popular repo and you’ll find a bunch of issues with dozens of “+1” reactions and that are closed as stale. Just because no one is working on a bug it doesn’t mean it doesn’t exist. Heck I regularly see maintainer themselves fighting the stale bot over the months. It’s hilarious to see because they do it to themselves. - closed because stale - reopened - closed because stale - reopened The only issues that could be closed automatically are those that are not reproducible and are abandoned by the author. With no further details nor “me too”s, then it’s fine to close as stale.
      - majkinetor 5y ago
        > It absolutely isn’t. Look at Mozilla’s bugzilla instead: You’ll find plenty of bugs open for years and eventually fixed. So? Its still stale issue. Stale issue get fixes some times, but most of the time they don't. So its a metric. If you need good examples, Redmine is probably greatest example as in any major release they have something that lived 10+ years as a ticket. >Plus, stale bots don’t take Reactions into consideration. That is not true. As soon as somebody comments on my Github repo after the bot announce that issue is going to be closed soon, it resets the period to 6mo again. So this is configuration setting. I have not seen so far that somebody says something else except equivalent of "its still not resolved" just to reset the period. So now I have tickets with that last couple of years with last several comments that it is not resolved :S. Totally meaningless. > Just because no one is working on a bug it doesn’t mean it doesn’t exist. Just because ticket is closed it doesn't mean bug is resolved. I usually have some form of meta label like resultion-wontfix, resolution-done, resolution-stale... > It’s hilarious to see because they do it to themselves. Its because they didn't get it. When you repeat the same meaningless thing over and over you should question the methodology.
rudian 5y ago
Stale bots sucks. You know what’s even worse? Bots that lock conversations after they’ve been closed by the owner. Like. What. The conversation is not over, you’re wrong, now I have to open a new issue.
- IshKebab 5y ago
  How about bots that close issues and lock conversations if the issue doesn't get enough thumbs ups within 30 days? I'm looking at you VSCode. Just tag them "unpopular" if it makes you feel better.
rnhmjoj 5y ago
I think a useful approach is, instead of closing or locking the issue, to have a bot that periodically (say every 90 days) pings everyone involved in that issue and tags it as "stale" if no one replies, but nothing else. Issues do get stale: maybe the problem has been solved in the meantime or is no longer relevant, in which case you close the issue, and if the problem is still there, it's nice to have a reminder.
- mikl 5y ago
  That would be a huge pain in the ass for maintainers of even mildly popular open source projects. They’d be getting an avalanche of such mails on the daily.
  - rnhmjoj 5y ago
    It is when you're watching all the activity in the repository, but this is already an avalanche of mails if the project is very large. If you only get notifications for issues you've actively partecipate in, it's fine.
  - manwe150 5y ago
    As a maintainer of such, there is already an avalanche of mail. The suggestion though can help to give PRs/issues one final chance at eyeballs before it gets to be old. It is similar to a “bump” comment, which is generally considered useful after 1-2 weeks.
hoseja 5y ago
Microsoft just automated their outsourced drone dismissing your issue because they couldn't be bothered to accept it.
gizdan 5y ago
I sympathise with this, however, I disagree that it's harmful at all times. I think having it misconfigured it's definitely harmful. The way I handle it is essentially never setting up automatic thread locking, and then, default to closing the issue, unless I add some specific label. This is mostly for my sanity. There's a lot of issues where you get an issue raised with "x doesn't work", with little to no information. Great, I can't do anything with that, so I push back, and often you don't hear anything back. At this point, I close it (or rather, stale bot does after inactivity). If the user then provides more information and the issue is triaged and valid, I add a label, which makes sure stale bot does not close the issue. If an issue does get closed, I'll get a notification if someone ends up commenting, and I can take appropriate action. It also gives others the opportunity to comment if they can provide additional context.
- geerlingguy 5y ago
  This is exactly how I use it. Some people do complain, and I get it. But they don't realize that 98% of all issues are spam that clutters up the issue queue, and outside of dedicated time just sitting around labeling issues and manually closing them, there would be no way for maintainers of anything near-popular to sift through issues for anything that actually matters. As it stands, a few of my moderately popular repos get on average 5-10 new issues per day. One of them might have any relevance towards improving the project. I don't see the same people who complain about stale bots volunteering to sit there babysitting issue queues closing irrelevant ones and responding to, essentially, free support requests.
  - cxr 5y ago
    You're way mistaken; there are absolutely people who recognize that these bots suck and also dump on the GitHub community for its tendency to abuse bugtrackers for dumb stuff like support requests and general project discussion. This comprises like half of my GitHub-related comments on HN. (The other half includes complaints that the GitHub generation has rendered the word "wiki" meaningless by applying it to things that are clearly not wikis and then taking an IDGAF attitude if you bring it up. The author of the blog post here is among the guilty.) Good bug discipline isn't new. It was understood at least 20 years ago and widely practiced with Bugzilla. GitHub and the types of users who go for it, though, seem to have a bent on organizational and operational regression. It's more important to chase self-actualization by doing things that feel productive because they keep you busy rather than thinking critically about how to actually be productive, apparently.
woodruffw 5y ago
I agree with this generally, but I’ll offer a bit of nuance for an edge case: for extremely active repositories with “rolling” changes (i.e., ones where it’s a user error to not be on the latest HEAD), stale bots do a great job of handling the “it broke for me last week, but I haven’t tried any of the changes since” issues that frequently occur.
- IshKebab 5y ago
  They do a great job of closing those issues, and also issues that are still valid. Not very useful. The problem is that there's no way to say to stalebot "this issue won't magically be fixed by time, I'm not going to comment here every 3 months to keep it open".
chmod775 5y ago
At this point I'd have to revive about five outstanding things a month because of bots like these. But I can't be bothered anymore. Sucks for the people who won't realize there's - sometimes quite important - things wrong with these projects. Handling and communicating well is an important aspect of quality in software development land and if a project is using such a bot it's probably falling short on that front. Bonus points if they have like 1.7k open issues anyways, lots of them duplicates of automatically closed ones.
vadfa 5y ago
Idea: a script for Thunderbird, mutt, etc. that automatically replies to all stale bot notification emails so the issues get reopened.
throwaway2037 5y ago
I love the opening line: <<Disclaimer: I work for a GitHub competitor.>> Instead, should that read...? <<Disclaimer: I own a GitHub competitor.>> For other readers, Drew is the founder / owner of SourceHut (https://sr.ht/ https://sr.ht/, https://sourcehut.org/ https://sourcehut.org/), and he is an excellent blogger! Please correct if I am wrong about Drew's role as founder / owner.
gfosco 5y ago
Obviously it's a subjective thing. I disagree with Drew and his incredibly entitled perspective on this completely. As a user of OSS, the project owner owes me nothing at all, and has no responsibility to field my requests, however valid they may be. From a solo dev to a large team, there's still only so many barrels in your gun. Mad that no one fixed it? Send a PR. Issues is not a customer service counter. It's not like project owners can't still see / search / work on closed tasks. They could still maintain data elsewhere about tasks which didn't get priority, or with a click or two see every stale issue that was closed.. I used to work on OSS health, and feel very strongly it's much worse (for most projects) to have hundreds/thousands of open issues stretching years.
- rightbyte 5y ago
  > As a user of OSS, the project owner owes me nothing at all That is not how human relations work. If you give away free lemonade on you driveway it has to be drinkable. The "not fit for any particular purpose" is legaleaze BS and everyone knows it. Of course there has to be rim and reason. And any project can be marked as "abandoned" or whatever, etc. But a FOSS project do owe the users honesty, or being called out for it.
  - throwmamatrain 5y ago
    Software is not lemonade. As for the bot, this is grown of "all tasks must be completed" "Inbox zero" type of thinking. Feels like we're holding issues wrong, but that is my view. There are tons of projects/scripts/junk I've put online that do a thing, or have done a thing, and putting it out there might be useful for someone. You will likely need to know something to use it, if not, it's not up to me to handhold you. I'm not going to go dig deep on some module I wrote for ImageJ eight years ago to solve someone's problem. It did work for me, and it's up to you to figure out if it works for you. I don't like your line of thinking because it adds a burden to publishing, "What happens if it burns down someone's house or dog?!" FOSS projects owe users NOTHING, you are free to do whatever you want. If it's useful to you, great. If you have a problem, it is your problem! Don't like it? Fork it. You can run your own version. Griping at someone on their issue tracker because it doesn't do a thing you want is what causes burnout and conflict. We're all people, so try to see it from their perspective as well. In my view, there is no such thing as abandoned software in open source. This is a contrivance of the latest hot framework js world.
johnsoft 5y ago
I'm just waiting for someone to create a "fresh bot" that replies automatically so issues don't get closed.
amitkgupta84 5y ago
Feels like GitHub issues needs states other than Open or Closed. How about: Resolved - issue has been fixed/addressed Won’t Resolve - addressing the issue is not aligned with the direction of the project; it is not and will not be resolved Paused - issue is valid but no one is continuing to discuss it, explore it, or work on it at this time; someone can resume the issue if they have new data or ideas. Maybe issues aren’t just “tasks” but they’re part of your work, and you need some tools to prioritize your work and help communicate to yourself and others what you’re focusing on and what state things are in.
- joshuaavalon 5y ago
  GitHub issues have labels. You can add "Resolved", "Won’t Resolve", "Paused" as you like. Many large repositories use labels to show the state of the issue. You do not need to rely on open or closed.
  - amitkgupta84 5y ago
    Of course, but I think there’s a benefit to having these be first class states rather than just labels.
faho 5y ago
What we do is to lock closed issues after a certain time without activity (currently a year). The idea is if it's been closed that long, a new issue should be filed so you get the context refreshed, and any patch for the original problem would also (most likely) have been in a release already, so it deserves a new issue so we can e.g. link to it in the release notes. The closing part is all manual, tho.
- cxr 5y ago
  The only reason to lock things would be because your userbase can't be trusted to behave responsibly—which, granted, is exactly the expectation of the average GitHub user. In a well-run project, the bugtracker is part of the project's digital memory. This means that the appropriate thing is to cross-link the new bug and the old bug. Not doing so—or being unable to do so because the original bug was locked—makes triage and archaeology needlessly difficult. Say hello to selection pressure: you drive away the most valuable collaborators and are left with the ones that you're spending all your time trying to protect yourself against.
  - deleted 5y ago
    [deleted]
teddyh 5y ago
I agree. If a user reports a legitimate bug, it lies on the maintainer to act on this information. If the maintainer ignores the bug and makes other random changes to the code, it still is the maintainer’s responsibility to fix the bug – the fact that they made it harder to find the bug by altering the code is entirely their own doing. It does not fall upon the bug reporter to test the code for bugs for every change made. To demand this, and to close the bug when they do not comply, is entirely the wrong thing to do.
- xtracto 5y ago
  > If a user reports a legitimate bug, it lies on the maintainer to act on this information. If the maintainer ignores the bug and makes other random changes to the code, it still is the maintainer’s responsibility to fix the bug This mentality is what prevents me from open sourcing most of my for-fun projects. The fact that there is people that as soon as I publish my code in Github, and someone finds it useful, they will put me as "responsible" for fixing whatever bug is affecting someone else. In my view, if I were to open source some of my code, it will be on an "as is" basis. If someone gets my code and burns his house, it is not my problem. I do my code to scratch my own itches, and don't really agree with catering to some 3rd party entitlement over some free text I share on the internet.
  - teddyh 5y ago
    Just because you are the author does not make you the maintainer. If you, obviously and clearly, announce to all users that this software is effectively unmaintained, then I have no problem. It’s when authors try to eat their cake and have it too that I have a problem; i.e. when authors want the fame and renown of being seen as responsible for widely-used software without doing the maintenance work necessary, then I have a problem.
joeyh 5y ago
I have a simple rule for people who close my bug reports this way: No further bug reports.
bjourne 5y ago
Pretty please all maintainers, please stop using this bot! I usually take the time to write well-written bug reports for any problems I spot. If my reports are closed as "stale" by this bot, that is a surefire way to get me to never report a single bug again and probably also to stop using the project altogether. It's demeaning because the bot is telling me that I wasted my time and that I shouldn't bother. Next to patches languishing for years, this is the absolutely most annoying "misfeature" of any free software project. Please stop!
beart 5y ago
The stale bot is trying to solve a set of problems with a single solution that fits almost none of them. Old issues never resolved? Not enough information? Too many issues created? Issues that will never be worked on? Just one solution - close them all without comment, while also spamming the inboxes of anyone who might be watching them... which leads to +1 posts and duplicates and "why was this closed?" - again more spam. Most people just want some sort of explanation that makes sense. Even something as simple as, "Don't have time for this right now, try reopening in 6 months" would be better, while accomplishing the same thing - closing issues that won't be worked on. In my experience, the number one problem I see on github / gitlab projects, is the maintainers not being able to or willing to allow others help them. Volunteering to triage issues, review code, etc. is very often meant with silence or reservations, even on projects that are specifically asking for help. Maintainers want help but they are very untrustworthy of those who wish to help them. That's completely understandable. The work is their baby and they want control over it. The internet is full of people who are untrustworthy. But this is a huge problem and there are a ton of open source projects that die as a result. The tools offered do not provide a good solution for this ownership problem, but they are all that is offered, so things like stale bot are used to try to reduce the load on the maintainers, which ends up making the problem worse, not better. There are some projects that don't run into these issues, at least not to the same degree. Those projects almost always have a high degree of collaboration between maintainers and contributors. It usually feels more like a collective than a maintainer/user relationship.
lars512 5y ago
This seems just like an argument about who Github Issues are for. Are they a community support forum, or a workflow tool for maintainers? Surely in both cases, it's the maintainer's choice. Personally, I find stale bots are refreshing in their honesty about what people actually have capacity and willingness to chase down and solve. They definitely can improve life for maintainers by turning an issues list into a manageable workflow.
donatj 5y ago
When we got bought out, there was some kind of push to "look like we're busy" or something. Our PMs closed a ton of old issues "because they're old". They're old, but they're still issues. We still have the problems with the product, there's just no note of them now. That's not better.
noaheverett 5y ago
A Github issue for OpenZFS I was following for a year was recently closed via stale bot. I just assumed the feature was dead, however on Twitter (yesterday) they announced the feature's author was giving a talk about implementing it, so I guess it's back on! I personally wish issues weren't auto-closed as it can give the wrong (i.e. feature is dead) impression, however I know popular OSS maintainers get a TON of issue requests and are doing a work of love. So, thank you OSS maintainers, you the real MVP. P.S. For those interested, the issue[1] is NVMe performance for OpenZFS[2] [1] https://github.com/openzfs/zfs/issues/8381 https://github.com/openzfs/zfs/issues/8381 [2] https://twitter.com/OpenZFS/status/1452762896769953795 https://twitter.com/OpenZFS/status/1452762896769953795
TheRealPomax 5y ago
"sr.ht provides mailing lists (and, soon, IRC chat rooms)" what year is this?
dom96 5y ago
I disagree with this and I guess most here. I think the screenshot that Drew displays is actually showing a stale bot that's misconfigured, maybe this is how GitHub's stale bot works by default, but I would say the crucial bit is that the stale bot should give issues a chance to be kept alive. After all, an issue that has people who care about it enough to comment isn't stale at all. Issues which are truly stale deserve to get a ping from the stale bot: "Is this issue still relevant? If I don't see anyone comment then I will close this issue in 7 days". Then after 7 days of inactivity the issue should be closed. Why do this? Because it enables prioritisation. Fixing every single issue is unrealistic and something that might have been a pain to someone in the past they may no longer care about.

338 points by als0 5y ago

I ran into this a few weeks ago with a PR I submitted. Auto-closed as stale after ten days after no interaction with a human. As someone who's been on both sides of writing and using software, this is not a good way to encourage people to use and contribute to a project.

joshxyz 5y ago

Got pissed off on it on ioredis repo. Project touts its low open issue count but most of its closed issues are bugs unaddressed by the maintainers. Fucking stupid.

throwaway439893 5y ago

> I’m not sure what motivates maintainers to install this on their repository If you knew why it was being used, you might not "consider it harmful"

MereInterest 5y ago
Please interpret the author's words charitably. In the context of the rest of the article, the opening sentence doesn't imply ignorance of the reasons why it is used, but rather understanding those reasons and finding them insufficient.

selfhoster11 5y ago

Hell yes. If you have an open issue, you have an issue. It doesn't disappear because you wish it away with a bot. Ticket overload may be a problem, but stale bots do not solve it.

ajsnigrutin 5y ago
This depends There might be an issue like "I get an error message, and then the software crashes!", you ask "what error message? What version? What does the log say?", and you never get a response, and the issues gets burried and forgotten.
- Snetry 5y ago
  Yes, but a stale bot is not going to stop those from appearing and will close issues with steps to reproduce and tracebacks
  - darkwater 5y ago
    Exactly. If you want to improve quality of reports, GH now let's projects even ask some questions before opening an issue, to redirect users to the proper channel. And if the proper channel is an issue, there is the ISSUE.md template that has been working for several years already now.
    - dhaavi 5y ago
      I only know the issue templates with the chooser. Can you point me to the feature you referred to with „GH now let's projects even ask some questions before opening an issue“?
      - darkwater 5y ago
        We are probably talking about the same feature. What I meant was this kind of page https://github.com/home-assistant/core/issues/new/choose https://github.com/home-assistant/core/issues/new/choose
        imtringued 5y ago
        That looks fantastic.
        dhaavi 5y ago
        Ok. Thanks. That’s how we use it too. I guess the question thing got me confused.
        darkwater 5y ago
        Yeah sorry for that, it's a multichoice page which inherently asks you a "what are you trying to do?" question.

moffkalast 5y ago

I am Jack's complete lack of surprise

chrismorgan 5y ago

A previous thread on an article about stale bots: https://news.ycombinator.com/item?id=25821092 https://news.ycombinator.com/item?id=25821092 Closing issues automatically is bad enough—I’ve long complained about the stale bot, seeking for it to be discontinued with prejudice as it’s only harmful, literally never helpful (as an issue tracker, that is—it may possibly help maintainers’ mental state because it can facilitate more effective ostrich imitation than just ignoring the issues as they pile up). Then there’s the GitHub action that has largely supplanted it (and which is what’s actually in the screenshot), which doesn’t just close, but locks (no idea if it’s configurable). A bot to close issues I can understand, people have been copying this misfeature from other sorts of trackers (… where it’s also normally a misfeature) for a long time. But making it lock issues is an even stupider idea than closing, amplifying the problems of closing even further for no reason that I can imagine, and I am baffled that that ever got implemented at all. I think it’s indefensible, but I’m rather curious to hear a defence of it.

oauea 5y ago
The best part is when the developers then close & lock your new issues as duplicates. No discussion allowed, I guess.
- pas 5y ago
  stay calm & fork
- deleted 5y ago
  [deleted]
- joshxyz 5y ago
  This is borderline absurd i cant comprehendo anymore hahahah fuck
nyuszika7h 5y ago
I agree, this is incredibly frustrating. Sometimes it's hard enough to even get developers to reopen issues closed for inactivity, if they're locked it's even worse. I often don't even bother trying to open a new issue for the same thing unless it's critical, I just leave in frustration.

quadrifoliate 5y ago

In my experience, these auto-closing bots are the natural result of software development workflows that treat issues as tasks to be closed, rather than a data point that a user is experiencing a problem of some kind (maybe they are doing things wrong, expecting something the project doesn't provide, or triggering a real problem – the exact cause is immaterial). This treatment of issue-as-a-task is made worse by corporate micromanagement frameworks like Agile, which encourage metrics on how many of these issues-as-tasks are closed, which leads to ill-advised features like this that close them automatically because "Duh, no one said anything in 30 days". If I were to design this myself, I would argue that the correct way to treat an issue is not to have it have a closed or open state at all. If the issue spawns a task or related tasks, you can close those. Or you can provide feedback on the issue that states that it is invalid. The user has already experienced a problem or wants a feature, there is no value in putting a red label that indicates "I'm done with this, please go away". It unnecessarily invalidates the experience of users who have their provided valuable time to report something to your software project. I think this is similar to the approach used by forums like Discourse, where a thread about a problem will usually not be closed or locked, but will just age out of current discussion if nobody brings it up.

c7DJTLrn 5y ago
Yep. GitHub Issues is not a scrum board and shouldn't be treated as such. It's for consumers to discuss with authors and other consumers.
- pc86 5y ago
  If its point is really consumer discussion with authors (I don't think it is) then Issues is a pretty terrible name for it. Given the overall quality of GitHub in literally every other aspect of the product, I find that unlikely.
  - npteljes 5y ago
    Yes, I think this is it. It all might have been started as "bugs" or "Issues" but over time, the functionality was extended to have feature requests, different discussions, etc. I don't have an alternative name for this, Notes maybe? But Issues sounds more severe than what it usually is.

cedws 5y ago

Completely agree with Drew here. Nothing pisses me off more than seeing an issue I care about or raised closed because it was "inactive". Just why? If issues went away by themselves we'd all be out of jobs. All these bots do is piss off the consumers and make your life harder by losing discussions. They also waste the time of those who put a lot of effort into their report to be helpful, encouraging lazy spam issues to be created in their place. GitHub should remove this disgraceful bot.

fireflash38 5y ago
It also makes it so that you get a ton of effectively spam comments on an issue to keep it 'active'. That said, I guess it's got some value in that it forces someone to become a squeaky wheel by bumping an issue they want to get fixed?
- gaius_baltar 5y ago
  I then wonder if somebody has a bumpbot now, just to prevent these issues from being closed by stalebot. :)
  - techdragon 5y ago
    I was going to ... In fact I just did a bunch of research for half an hour. I picked a language, hosting, UI tools, looked up the API calls and worked out how to do most of the mechanical process behind the scenes. Despite being a decent idea and a product I'd 100% use myself, I'm not sure I should do any more work on the idea due to GitHub's Acceptable Use Policy... > 10. User Protection > You must not engage in activity that significantly harms other users. We will resolve disputes in favor of protecting users as a whole. I can see a lot of arguments that GitHub could use to label any kind of automatic "bumpbot" bot/tool/service in widespread use as violating this clause. If I was more confident it wouldn't get ban-hammered and shutdown, I'd pop back open that folder of notes and get at it.
  - remram 5y ago
    I was considering making a browser plugin to have a one-click button to comment "this issue is not going away by itself, please read it before you decide it's stale" or similar. Now that ddevault wrote this it might be a good resource to put in there. Making a completely automated bot certainly falls short of GitHub's acceptable use policy.

Longhanks 5y ago

“Considered Harmful” Essays Considered Harmful https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html

vemv 5y ago

Devil's advocate: some projects are extremely open-ended and will always have issues, hundreds of them. Bugs will be a permanent condition of the project so some bugs might be not deemed relevant, ever. Auto-closing helps here. If nobody is attending a given issue, definitionally it doesn't have an economic value: nobody deemed the issue/task worth solving OR paying for it. It might be annoying, but not sufficiently annoying to take action. It doesn't block your business, workflow, productivity etc; if it was, you'd be personally involved in solving the issue in some or other way.

MereInterest 5y ago
> Devil's advocate: some projects are extremely open-ended and will always have issues, hundreds of them. Open-ended projects may have design/feature request issues, but those should be distinct from bug reports. And those design/feature request issues are exactly the kind that most require human interaction, to decide whether something should be part of the program. > Bugs will be a permanent condition of the project Bugs are a fact of life for any developing software. Any particular bug is not. Closing an issue is a statement about that particular bug being fixed. Auto-closing an issue due to staleness is a lie that the bug has been fixed. That said, if there's an automated reproducible test case for the bug, then it could be closed when that reproducible test case passes. If a seemingly unrelated change resolves the issue, and that can be verified, then it would be acceptable to auto-close the issue as a result. > so some bugs might be not deemed relevant, ever. Auto-closing helps here. There's a big difference between "not deemed relevant" and "deemed not relevant". The former is when you have an issue that sits open for some time, and sure, that might not be relevant right now, but could be important later. The latter is an active decision that something is irrelevant and never will be relevant. That's the message received from an issue being closed, which is a far more aggressive message. Auto-closing delivers this aggressive message, throwing away the work somebody has done in reporting the issue, without even so much as an acknowledgement. > if it was, you'd be personally involved in solving the issue in some or other way. Reporting an issue is being personally involved in solving it. Writing a solid issue, clearly documenting how to reproduce, expected behavior, observed behavior, why the expected behavior would be closer aligned with other behavior in the program, etc, takes time and effort.

laurent123456 5y ago

I rely a lot on stale bot actually, simply because I don't like closing issues. When you do that, users sometimes get upset and you have to explain that this is not a bug, or it's a duplicate of another bug, or that we use GitHub issues as a bug tracker, not for support, etc. Then the user might argue that it's not exactly the same bug, or that we should leave it open for reason x or y. It's a time consuming process that needs to be repeated very often when you manually close bugs. And it's mostly worthless because we know what we're doing - we know what will be worked on, what will be ignored. We just tag the issues that we'll work on and Stale Bot will skip these. So now I don't close anything anymore and let users get mad at Stale Bot instead. It's a bit weird but the end result is the same.

fistynuts 5y ago
What an odd point of view. It doesn't sound like you respect your users at all.
- shp0ngle 5y ago
  If you have even a mildly successful github repository, you will understand. People are weirdly entitled and feel like you really, really must fix the bug. Often with no real actual datapoints or way to reproduce. Still, auto-closing bots are annoying. But I see why people might want them
  - geerlingguy 5y ago
    And there are a ton of non-bug issues that people feel entitled to your time (as a maintainer) to respond to and help them. Often for many, many comments. Unfortunately, most maintainers just don't have the time to handhold 5-10 users per day for there projects, not when that means they'd not have time for other things, like family, recreation, etc. We have extremely limited time, it's an impossible task to manually handle the deluge of issues.
    - berkes 5y ago

spondyl 5y ago

The CADT model seems relevant here: https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html

mikl 5y ago
You can’t link jwz.org from here, he’s set up referrer detection so you get an image of a testicle in an egg holder if you follow a link from here.
- techdragon 5y ago
  Worked for me in Safari on macOS. (I'm not sure if that's because of Safari or jwz though)

fabian2k 5y ago

While I think that closing issues after a certain time is really problematic, there is an inherent problem with a certain subset of stale issues. The most problematic part is that the older issues become irrelevant over time, in part because the system changed too much and they don't apply anymore or because the people originally asking aren't interested anymore in the answer. If you just accumulate old issues it becomes hard to find still relevant issues in this whole pile. I don't think closing based on time is always a bad idea, but you should have a good mechanism to save issues that are relevant from the bot. In the end you always need some minimal triage on issues to keep them usable.

TrianguloY 5y ago

Also, on GitHub when you want to search an issue it filters by open only (you need to remove it manually). This brings on a lot of duplicated issues, so in some cases it increases the mantainers job.

majkinetor 5y ago

Nonsense. You can always browse closed issues. The fact that issue is closed means absolutely nothing to the promoted methodology.

rudian 5y ago
What’s the point of having an open/closed status if an unsolved bug is now “closed”? You might as well close Issues and use Discussions instead.
- majkinetor 5y ago
  The point is that visibility state of the ticket is irrelevant and not connected to the resolving state. The point of closed bug is one among the not confirmed, not affecting too many users, hard to fix, unable to fix, no time to fix, no interest in fixing it, higher priority fixes piled up etc... Staleness is also meaningful on its own. Let me repeat - Nonsence.
  - rudian 5y ago
    > Staleness is also meaningful on its own. It absolutely isn’t. Look at Mozilla’s bugzilla instead: You’ll find plenty of bugs open for years and eventually fixed. Plus, stale bots don’t take Reactions into consideration. Spend a week on a popular repo and you’ll find a bunch of issues with dozens of “+1” reactions and that are closed as stale. Just because no one is working on a bug it doesn’t mean it doesn’t exist. Heck I regularly see maintainer themselves fighting the stale bot over the months. It’s hilarious to see because they do it to themselves. - closed because stale - reopened - closed because stale - reopened The only issues that could be closed automatically are those that are not reproducible and are abandoned by the author. With no further details nor “me too”s, then it’s fine to close as stale.
    - majkinetor 5y ago
      > It absolutely isn’t. Look at Mozilla’s bugzilla instead: You’ll find plenty of bugs open for years and eventually fixed. So? Its still stale issue. Stale issue get fixes some times, but most of the time they don't. So its a metric. If you need good examples, Redmine is probably greatest example as in any major release they have something that lived 10+ years as a ticket. >Plus, stale bots don’t take Reactions into consideration. That is not true. As soon as somebody comments on my Github repo after the bot announce that issue is going to be closed soon, it resets the period to 6mo again. So this is configuration setting. I have not seen so far that somebody says something else except equivalent of "its still not resolved" just to reset the period. So now I have tickets with that last couple of years with last several comments that it is not resolved :S. Totally meaningless. > Just because no one is working on a bug it doesn’t mean it doesn’t exist. Just because ticket is closed it doesn't mean bug is resolved. I usually have some form of meta label like resultion-wontfix, resolution-done, resolution-stale... > It’s hilarious to see because they do it to themselves. Its because they didn't get it. When you repeat the same meaningless thing over and over you should question the methodology.

rudian 5y ago

Stale bots sucks. You know what’s even worse? Bots that lock conversations after they’ve been closed by the owner. Like. What. The conversation is not over, you’re wrong, now I have to open a new issue.

IshKebab 5y ago
How about bots that close issues and lock conversations if the issue doesn't get enough thumbs ups within 30 days? I'm looking at you VSCode. Just tag them "unpopular" if it makes you feel better.

rnhmjoj 5y ago

I think a useful approach is, instead of closing or locking the issue, to have a bot that periodically (say every 90 days) pings everyone involved in that issue and tags it as "stale" if no one replies, but nothing else. Issues do get stale: maybe the problem has been solved in the meantime or is no longer relevant, in which case you close the issue, and if the problem is still there, it's nice to have a reminder.

mikl 5y ago
That would be a huge pain in the ass for maintainers of even mildly popular open source projects. They’d be getting an avalanche of such mails on the daily.
- rnhmjoj 5y ago
  It is when you're watching all the activity in the repository, but this is already an avalanche of mails if the project is very large. If you only get notifications for issues you've actively partecipate in, it's fine.
- manwe150 5y ago
  As a maintainer of such, there is already an avalanche of mail. The suggestion though can help to give PRs/issues one final chance at eyeballs before it gets to be old. It is similar to a “bump” comment, which is generally considered useful after 1-2 weeks.

hoseja 5y ago

Microsoft just automated their outsourced drone dismissing your issue because they couldn't be bothered to accept it.

gizdan 5y ago

I sympathise with this, however, I disagree that it's harmful at all times. I think having it misconfigured it's definitely harmful. The way I handle it is essentially never setting up automatic thread locking, and then, default to closing the issue, unless I add some specific label. This is mostly for my sanity. There's a lot of issues where you get an issue raised with "x doesn't work", with little to no information. Great, I can't do anything with that, so I push back, and often you don't hear anything back. At this point, I close it (or rather, stale bot does after inactivity). If the user then provides more information and the issue is triaged and valid, I add a label, which makes sure stale bot does not close the issue. If an issue does get closed, I'll get a notification if someone ends up commenting, and I can take appropriate action. It also gives others the opportunity to comment if they can provide additional context.

geerlingguy 5y ago
This is exactly how I use it. Some people do complain, and I get it. But they don't realize that 98% of all issues are spam that clutters up the issue queue, and outside of dedicated time just sitting around labeling issues and manually closing them, there would be no way for maintainers of anything near-popular to sift through issues for anything that actually matters. As it stands, a few of my moderately popular repos get on average 5-10 new issues per day. One of them might have any relevance towards improving the project. I don't see the same people who complain about stale bots volunteering to sit there babysitting issue queues closing irrelevant ones and responding to, essentially, free support requests.
- cxr 5y ago
  You're way mistaken; there are absolutely people who recognize that these bots suck and also dump on the GitHub community for its tendency to abuse bugtrackers for dumb stuff like support requests and general project discussion. This comprises like half of my GitHub-related comments on HN. (The other half includes complaints that the GitHub generation has rendered the word "wiki" meaningless by applying it to things that are clearly not wikis and then taking an IDGAF attitude if you bring it up. The author of the blog post here is among the guilty.) Good bug discipline isn't new. It was understood at least 20 years ago and widely practiced with Bugzilla. GitHub and the types of users who go for it, though, seem to have a bent on organizational and operational regression. It's more important to chase self-actualization by doing things that feel productive because they keep you busy rather than thinking critically about how to actually be productive, apparently.

woodruffw 5y ago

I agree with this generally, but I’ll offer a bit of nuance for an edge case: for extremely active repositories with “rolling” changes (i.e., ones where it’s a user error to not be on the latest HEAD), stale bots do a great job of handling the “it broke for me last week, but I haven’t tried any of the changes since” issues that frequently occur.

IshKebab 5y ago
They do a great job of closing those issues, and also issues that are still valid. Not very useful. The problem is that there's no way to say to stalebot "this issue won't magically be fixed by time, I'm not going to comment here every 3 months to keep it open".

chmod775 5y ago

At this point I'd have to revive about five outstanding things a month because of bots like these. But I can't be bothered anymore. Sucks for the people who won't realize there's - sometimes quite important - things wrong with these projects. Handling and communicating well is an important aspect of quality in software development land and if a project is using such a bot it's probably falling short on that front. Bonus points if they have like 1.7k open issues anyways, lots of them duplicates of automatically closed ones.

vadfa 5y ago

Idea: a script for Thunderbird, mutt, etc. that automatically replies to all stale bot notification emails so the issues get reopened.

throwaway2037 5y ago

I love the opening line: <<Disclaimer: I work for a GitHub competitor.>> Instead, should that read...? <<Disclaimer: I own a GitHub competitor.>> For other readers, Drew is the founder / owner of SourceHut (https://sr.ht/ https://sr.ht/, https://sourcehut.org/ https://sourcehut.org/), and he is an excellent blogger! Please correct if I am wrong about Drew's role as founder / owner.

gfosco 5y ago

Obviously it's a subjective thing. I disagree with Drew and his incredibly entitled perspective on this completely. As a user of OSS, the project owner owes me nothing at all, and has no responsibility to field my requests, however valid they may be. From a solo dev to a large team, there's still only so many barrels in your gun. Mad that no one fixed it? Send a PR. Issues is not a customer service counter. It's not like project owners can't still see / search / work on closed tasks. They could still maintain data elsewhere about tasks which didn't get priority, or with a click or two see every stale issue that was closed.. I used to work on OSS health, and feel very strongly it's much worse (for most projects) to have hundreds/thousands of open issues stretching years.

rightbyte 5y ago
> As a user of OSS, the project owner owes me nothing at all That is not how human relations work. If you give away free lemonade on you driveway it has to be drinkable. The "not fit for any particular purpose" is legaleaze BS and everyone knows it. Of course there has to be rim and reason. And any project can be marked as "abandoned" or whatever, etc. But a FOSS project do owe the users honesty, or being called out for it.
- throwmamatrain 5y ago
  Software is not lemonade. As for the bot, this is grown of "all tasks must be completed" "Inbox zero" type of thinking. Feels like we're holding issues wrong, but that is my view. There are tons of projects/scripts/junk I've put online that do a thing, or have done a thing, and putting it out there might be useful for someone. You will likely need to know something to use it, if not, it's not up to me to handhold you. I'm not going to go dig deep on some module I wrote for ImageJ eight years ago to solve someone's problem. It did work for me, and it's up to you to figure out if it works for you. I don't like your line of thinking because it adds a burden to publishing, "What happens if it burns down someone's house or dog?!" FOSS projects owe users NOTHING, you are free to do whatever you want. If it's useful to you, great. If you have a problem, it is your problem! Don't like it? Fork it. You can run your own version. Griping at someone on their issue tracker because it doesn't do a thing you want is what causes burnout and conflict. We're all people, so try to see it from their perspective as well. In my view, there is no such thing as abandoned software in open source. This is a contrivance of the latest hot framework js world.

johnsoft 5y ago

I'm just waiting for someone to create a "fresh bot" that replies automatically so issues don't get closed.

amitkgupta84 5y ago

Feels like GitHub issues needs states other than Open or Closed. How about: Resolved - issue has been fixed/addressed Won’t Resolve - addressing the issue is not aligned with the direction of the project; it is not and will not be resolved Paused - issue is valid but no one is continuing to discuss it, explore it, or work on it at this time; someone can resume the issue if they have new data or ideas. Maybe issues aren’t just “tasks” but they’re part of your work, and you need some tools to prioritize your work and help communicate to yourself and others what you’re focusing on and what state things are in.

joshuaavalon 5y ago
GitHub issues have labels. You can add "Resolved", "Won’t Resolve", "Paused" as you like. Many large repositories use labels to show the state of the issue. You do not need to rely on open or closed.
- amitkgupta84 5y ago
  Of course, but I think there’s a benefit to having these be first class states rather than just labels.

faho 5y ago

What we do is to lock closed issues after a certain time without activity (currently a year). The idea is if it's been closed that long, a new issue should be filed so you get the context refreshed, and any patch for the original problem would also (most likely) have been in a release already, so it deserves a new issue so we can e.g. link to it in the release notes. The closing part is all manual, tho.

cxr 5y ago
The only reason to lock things would be because your userbase can't be trusted to behave responsibly—which, granted, is exactly the expectation of the average GitHub user. In a well-run project, the bugtracker is part of the project's digital memory. This means that the appropriate thing is to cross-link the new bug and the old bug. Not doing so—or being unable to do so because the original bug was locked—makes triage and archaeology needlessly difficult. Say hello to selection pressure: you drive away the most valuable collaborators and are left with the ones that you're spending all your time trying to protect yourself against.
- deleted 5y ago
  [deleted]

teddyh 5y ago

I agree. If a user reports a legitimate bug, it lies on the maintainer to act on this information. If the maintainer ignores the bug and makes other random changes to the code, it still is the maintainer’s responsibility to fix the bug – the fact that they made it harder to find the bug by altering the code is entirely their own doing. It does not fall upon the bug reporter to test the code for bugs for every change made. To demand this, and to close the bug when they do not comply, is entirely the wrong thing to do.

xtracto 5y ago
> If a user reports a legitimate bug, it lies on the maintainer to act on this information. If the maintainer ignores the bug and makes other random changes to the code, it still is the maintainer’s responsibility to fix the bug This mentality is what prevents me from open sourcing most of my for-fun projects. The fact that there is people that as soon as I publish my code in Github, and someone finds it useful, they will put me as "responsible" for fixing whatever bug is affecting someone else. In my view, if I were to open source some of my code, it will be on an "as is" basis. If someone gets my code and burns his house, it is not my problem. I do my code to scratch my own itches, and don't really agree with catering to some 3rd party entitlement over some free text I share on the internet.
- teddyh 5y ago
  Just because you are the author does not make you the maintainer. If you, obviously and clearly, announce to all users that this software is effectively unmaintained, then I have no problem. It’s when authors try to eat their cake and have it too that I have a problem; i.e. when authors want the fame and renown of being seen as responsible for widely-used software without doing the maintenance work necessary, then I have a problem.

joeyh 5y ago

I have a simple rule for people who close my bug reports this way: No further bug reports.

bjourne 5y ago

Pretty please all maintainers, please stop using this bot! I usually take the time to write well-written bug reports for any problems I spot. If my reports are closed as "stale" by this bot, that is a surefire way to get me to never report a single bug again and probably also to stop using the project altogether. It's demeaning because the bot is telling me that I wasted my time and that I shouldn't bother. Next to patches languishing for years, this is the absolutely most annoying "misfeature" of any free software project. Please stop!

beart 5y ago

The stale bot is trying to solve a set of problems with a single solution that fits almost none of them. Old issues never resolved? Not enough information? Too many issues created? Issues that will never be worked on? Just one solution - close them all without comment, while also spamming the inboxes of anyone who might be watching them... which leads to +1 posts and duplicates and "why was this closed?" - again more spam. Most people just want some sort of explanation that makes sense. Even something as simple as, "Don't have time for this right now, try reopening in 6 months" would be better, while accomplishing the same thing - closing issues that won't be worked on. In my experience, the number one problem I see on github / gitlab projects, is the maintainers not being able to or willing to allow others help them. Volunteering to triage issues, review code, etc. is very often meant with silence or reservations, even on projects that are specifically asking for help. Maintainers want help but they are very untrustworthy of those who wish to help them. That's completely understandable. The work is their baby and they want control over it. The internet is full of people who are untrustworthy. But this is a huge problem and there are a ton of open source projects that die as a result. The tools offered do not provide a good solution for this ownership problem, but they are all that is offered, so things like stale bot are used to try to reduce the load on the maintainers, which ends up making the problem worse, not better. There are some projects that don't run into these issues, at least not to the same degree. Those projects almost always have a high degree of collaboration between maintainers and contributors. It usually feels more like a collective than a maintainer/user relationship.

lars512 5y ago

This seems just like an argument about who Github Issues are for. Are they a community support forum, or a workflow tool for maintainers? Surely in both cases, it's the maintainer's choice. Personally, I find stale bots are refreshing in their honesty about what people actually have capacity and willingness to chase down and solve. They definitely can improve life for maintainers by turning an issues list into a manageable workflow.

donatj 5y ago

When we got bought out, there was some kind of push to "look like we're busy" or something. Our PMs closed a ton of old issues "because they're old". They're old, but they're still issues. We still have the problems with the product, there's just no note of them now. That's not better.

noaheverett 5y ago

A Github issue for OpenZFS I was following for a year was recently closed via stale bot. I just assumed the feature was dead, however on Twitter (yesterday) they announced the feature's author was giving a talk about implementing it, so I guess it's back on! I personally wish issues weren't auto-closed as it can give the wrong (i.e. feature is dead) impression, however I know popular OSS maintainers get a TON of issue requests and are doing a work of love. So, thank you OSS maintainers, you the real MVP. P.S. For those interested, the issue[1] is NVMe performance for OpenZFS[2] [1] https://github.com/openzfs/zfs/issues/8381 https://github.com/openzfs/zfs/issues/8381 [2] https://twitter.com/OpenZFS/status/1452762896769953795 https://twitter.com/OpenZFS/status/1452762896769953795

TheRealPomax 5y ago

"sr.ht provides mailing lists (and, soon, IRC chat rooms)" what year is this?

dom96 5y ago

I disagree with this and I guess most here. I think the screenshot that Drew displays is actually showing a stale bot that's misconfigured, maybe this is how GitHub's stale bot works by default, but I would say the crucial bit is that the stale bot should give issues a chance to be kept alive. After all, an issue that has people who care about it enough to comment isn't stale at all. Issues which are truly stale deserve to get a ping from the stale bot: "Is this issue still relevant? If I don't see anyone comment then I will close this issue in 7 days". Then after 7 days of inactivity the issue should be closed. Why do this? Because it enables prioritisation. Fixing every single issue is unrealistic and something that might have been a pain to someone in the past they may no longer care about.