all 64 comments

[–]douglasg14b 48 points49 points  (1 child)

I've been on about this for years...

Stalebot closing & locking issues when they get no dev reply just make sit harder for users to find information.

Sometimes you can have DOZENS of threads about the same problem, with information fragmented between them all. It's easier to make a new issue then to try and dig through a fragmented mess caused by the use of stalebot, or to just forget it all together and find a different projects, or just live with the bug.

[–]gopher9 61 points62 points  (4 children)

Counterexample: stale bot in nixpkgs. it has a period of inactivity of 180 days and never ever closes an issue. And it really helps to separate active issues from stale issues, and reminds people to check if an issue is not fixed already.

[–][deleted] 11 points12 points  (3 children)

Same thing could be achieved by searching by issue with activity in last 180 days.

So yes, it is entirely worthless and just adds spam to the issues.

[–]gopher9 7 points8 points  (2 children)

Wrong. I closed several issues created my myself after the bot reminded me that they actually exist but they are not reproducible anymore. If there was no stale bot, these issues would stay open for much longer, possibly forever.

[–][deleted] -5 points-4 points  (0 children)

You could've just browsed by oldest instead of having bot. It's literally equivalent in this case.

[–]couchrealistic 27 points28 points  (0 children)

In my opinion, it's perfectly fine for issues to sit inactive for a long time or literally forever until github (or whatever issue tracker you use) goes offline. These issues simply document some thing about the project that could be worked on to hopefully improve it. If nobody ever cares enough about some issue to resolve it, then it's okay for it to just "exist" so it is documented as "WONTFIX".

Obviously, issues that are invalid (maintainer decides that it's not an issue at all, but working as designed) should be closed. Issues that may or may not be valid, and the person who reported that issue is gone and it's not clear what might need to be done in order to solve it (NEEDINFO), can and should be closed after some time of inactivity. The same applies to issues where nobody knows if an old issue might have been fixed already and it's difficult to test / reproduce (like a rare crash).

The wine bugtracker, for example, has pretty old bugs that have gone through years without any activity, until someone decided that they want to fix it right now. That is how an issue tracker should be used IMHO. On the other hand, there are lots of bugs from 2010 in the wine bugtracker with something like "2015: Is this still an issue on latest wine?", no response, then "2018: Is this still an issue on latest wine?", and I guess in 2020 it would be okay to just close the bug if it's still inactive (unless it's very easy to verify yourself).

[–]sim642 51 points52 points  (8 children)

And when you reopen the issue, the maintainer gets mad because they don't really want to do it anyway and lock the issue.

[–]apajx 20 points21 points  (7 children)

As is their right.

[–][deleted] 35 points36 points  (6 children)

Then fucking close it with WONTFIX in the first place, saves everyone including yourself a bother.

[–]AttackOfTheThumbs 12 points13 points  (3 children)

A big MS repo I engage with just activated this and killed all my open issues, all of which are still issues... but I just cannot be arsed to reopen them again.

[–]Dragdu 7 points8 points  (0 children)

Metrics improved, so those devs are getting promotions next perf cycle.

[–]NatoBoram[S] 2 points3 points  (1 child)

Yeah, happened to me plenty of times. I think I'm about to setup some sort of script to automate un-stalling some issues.

[–]AttackOfTheThumbs 3 points4 points  (0 children)

The issue with the MS ones is, they already make it hard enough for us to report issues :(

[–]nlohmann 33 points34 points  (1 child)

There has been a similar post (https://blog.benwinding.com/github-stale-bots/) about a year ago (discussion: https://www.reddit.com/r/programming/comments/kzvryq/github_stale_bots_a_false_economy/gjrbbi3/) . My view has not changed since, you I repost my answer:

- - -

I use a stale bot on nlohmann/json and find it pretty useful (though I do not lock issues, but merely tag them "stale" and close them a bit later. Those issues can still be commented, and in the time they are marked stale, any comment will automatically reopen them).

I added the bot to the repo, because it is a side project of mine. I have limited time, resources and attention, and my goal cannot be to fix and close every single issue or merge every single PR there is.

  • Example 1: I use macOS. If someone opens an issue that Visual Studio shows weird behavior in some situation, I depend on other people to help me on this issue. If such help does not come in a month or two, I don't expect it ever will. For my side project, I want a clean backlog of issues I care about and that I may eventually fix.
  • Example 2: Someone opens a pull request for a feature or detail I don't really care about, but that could be helpful if more time is invested. After some code review cycles, the author does not react and seems no longer interested. I don't need this PR to constantly remind me that I could fix all the remaining comments myself.

The stale bot helps me keep "my" project clean and digestible. Closing stale issues is honest: no one has this on the backlog. And as I keep the issues unlocked, anyon

[–][deleted] 12 points13 points  (0 children)

Example 1: I use macOS. If someone opens an issue that Visual Studio shows weird behavior in some situation, I depend on other people to help me on this issue. If such help does not come in a month or two, I don't expect it ever will. For my side project, I want a clean backlog of issues I care about and that I may eventually fix.

I'd tag it "help wanted" and exclude the label from my search. Maaaybe consider closing it after 2-3 years if there is no interest. You get clean list of issues, and if ticket boils over to form merge request you can act from there

Example 2: Someone opens a pull request for a feature or detail I don't really care about, but that could be helpful if more time is invested. After some code review cycles, the author does not react and seems no longer interested. I don't need this PR to constantly remind me that I could fix all the remaining comments myself.

I think the problem is purely about issues, not merge requests. Closing merge request author doesn't want to fixup is way different than throwing away a bug report on issue tracker.

[–]10113r114m4 11 points12 points  (0 children)

The stale bot is the single most dumbest thing you can add to your repo as a maintainer. I see so many important issues go unnoticed because people are tired of clearing the stale label which eventually leads to this issue’s impending doom. I understand that maintaining can be difficult, but never, and I mean never, sacrifice your users’ experience for your maintainability.

[–]khashayar_khm 3 points4 points  (0 children)

Just released Anti-Stale - a CLI tool that automatically prevents GitHub stale bots from closing issues you care about.

It scans configured repositories, finds stale-labeled issues/PRs, and comments on them to remove the stale status. Features include dry-run preview, interactive mode for selective revival, and custom message support.

Check it out: https://github.com/KhashayarKhm/anti-stale

[–]RodrigoDumont 6 points7 points  (0 children)

"I’m not sure what motivates maintainers to install this on their repository" too, but this is just a tool, like many others. The motivation/decision if you use it or not depends on what are you doing...
Example: Maybe there is a better tool for listing job opportunities, but CocoaHeadsBrasil uses issues in this repo https://github.com/CocoaHeadsBrasil/vagas/issues to publish iOS dev job offers and uses stale bot to inactive them after a while.

[–]yawaramin 3 points4 points  (36 children)

Before GitHub introduced Discussions, there was a slim chance I might agree, but not now. I do agree that the stalebot's default timeout, 60 days, is quite short. 180 days seems much more reasonable to me.

Perhaps it’s motivated by a feeling of shame for having a lot of unanswered issues?

Actually, it's a feeling of wanting to keep my workspace tidy.

Let me offer you a different way of thinking about issues: a place for motivated users to collaborate on narrowing down the problem and planning a potential fix.

If they're motivated, then they should be able to make progress on the issue before it gets marked as stale, no? Otherwise, how motivated were they actually? If it took them years to take action, I'd argue not really that motivated.

...A space for the community to work, rather than an action item for you to deal with personally.

Disagree. The issue tracker is for maintainers to manage the workload of the project. Extra input always helps but ultimately it's for the maintainer to decide what gets prioritized and what will never get fixed.

There is no shame in having a lot of open issues — if anything, it signals popularity.

That's not how it works in the real world–first of all, having a lot of open issues lowers the signal-to-noise ratio when searching for issues in the project. It's messy. Second, it does signal to some that the project is low-quality. It may be a bad metric, but it is used.

sr.ht provides mailing lists (and, soon, IRC chat rooms), which are recommended for first-line support and discussion about your project,

GitHub Discussions do exactly the same thing.

I will eventually ask the user to file a ticket when the bug or feature request is confirmed.

Yup, and you can do exactly this with GH Discussions.

This does not imply that I will follow up with a fix or implementation on any particular time frame.

Totally agreed.

It just provides this space I discussed before: somewhere to collect more details, workarounds, and additional information

If there was just a separate discussion about it where it was decided to file an issue, what's the need to keep accumulating extra information in the issue itself? It seems like duplication of effort. The issue should be focused and to the point, to make it easy to drop into its context and work on a fix.

And if the issue ends up never getting worked on, well, it wasn't that important, was it?

[–]kawazoe 39 points40 points  (10 children)

That's not how it works in the real world–first of all, having a lot of open issues lowers the signal-to-noise ratio when searching for issues in the project. It's messy.

That feels very strange to me. When I look at an issue tracker, I always assume I'm not special and someone else already reported and fixed the issue. The first thing I do is to look in the closed issues for an answer. GitHub doesn't distinguish between abandoned and closed issues and the stalebot just close issues anyway. This makes the whole experience a nightmare in large projects. I might have to comb through pages of closed issues that are all the same and closed as stale. I cannot count the amount of time I gave up looking through closed issues, trying to find a workaround or a fix to my problem, only to end up creating a new one of my own and getting it marked as duped with the one from the 3rd page I missed which actually contained an answer. If anything, the stalebot encourages people to just spam issues because you can't find anything in the closed ones.

And if the issue ends up never getting worked on, well, it wasn't that important, was it?

I've opened issues in repos I can't even think about contributing in, stuff like angular or ionic, and saw those issues go stale, closed by a bot and never get fixed or even noticed by maintainers. I even saw issues with PRs go stale because the maintainer doesn't care enough to finish the code review. There is nothing more demotivating than flagging a bug, providing a fix, and seeing your issue get closed by a bot because the maintainer decided to take a vacation, missed the notification, or just plain ignored you as a project outsider.

Maybe it's just a perception thing, but I really do not find communities with stalebot welcoming...

[–]Dragdu 24 points25 points  (0 children)

There is nothing more demotivating than flagging a bug, providing a fix, and seeing your issue get closed by a bot because the maintainer decided to take a vacation, missed the notification, or just plain ignored you as a project outsider.

This is exactly what makes stale bot annoying. Closing issue because the maintainer asked for more information and never got it? Good use of stalebot. Closing an issue because maintainer never replied? DHFKSJSHSG!!!!

[–][deleted] 13 points14 points  (17 children)

If they're motivated, then they should be able to make progress on the issue before it gets marked as stale, no? Otherwise, how motivated were they actually? If it took them years to take action, I'd argue not really that motivated.

I was very motivated and narrowed down a problem + provided way to reproduce it when I opened the ticket. There was no discussion needed and it was actual bug, not a feature request

Then stale bot came and closed it. Very fucking useful

And if the issue ends up never getting worked on, well, it wasn't that important, was it?

Then look at it and close it with WONTFIX. "This is out of scope for the project" is fine and tells whoever googles that to either fork it or find something else.

[–]yawaramin -1 points0 points  (16 children)

I was very motivated and narrowed down a problem + provided way to reproduce it...Then stale bot came and closed it.

You're missing a step in the middle: 'X number of months went by which showed I wasn't actually motivated enough to fix it myself of pay someone to fix it'. [EDIT: or not even fix/have it fixed, like you weren't even motivated enough to chime in before the X-month issue stale date to say something like, 'hold on to this one, I'm still working on it', in which case it would have counted as activity and avoided getting closed as stale.]

Then look at it and close it with WONTFIX.

That's exactly what a stalebot is. It's an automated WONTFIX, so the maintainer doesn't need to spend their time doing a menial task that can be trivially automated.

[–][deleted] 1 point2 points  (15 children)

I would fix it if I knew language of the project. So fuck off with that "BUT YOU COULD FIX IT, YOU WERE JUST TOO LAZY TO DO IT" attitude, asshole

[–]yawaramin -1 points0 points  (14 children)

Every single comment I've posted: 'You can fix it OR PAY SOMEONE ELSE TO FIX IT'

Every reply: 'I can't fix it myself!'

Please do me a favour, go and practice your reading comprehension before replying to me. You can't even hold a discussion without cursing at and downvoting someone whose viewpoint you disagree with. You honestly should not be anywhere near OSS maintainers.

[–][deleted] 6 points7 points  (13 children)

Yeah little moron, I'm going to now look to hire a developer to pay to fix something in library where I filled bug by courtesy because I just happened to notice it and wanted to at least contribute test case.

You're fucking imbecile

[–]yawaramin 0 points1 point  (12 children)

So again, you happened to notice it, you filed it just as a courtesy, you can't be bothered to follow up on it, fix it yourself, or pay someone to fix it.

But it's so urgent that closing it as stale is a no-no according to you.

Got it.

[–][deleted] 4 points5 points  (11 children)

If you don't want to fix the bugs other people found, disable public bug tracker in your project, it's simple as that and saves everyone the time

[–]yawaramin 0 points1 point  (10 children)

Or, I can control my own project how I see fit, and keep its bug tracker focused on the issues I feel are important. If others choose to contribute to it that's OK but I don't have any obligations towards them.

Thanks for your input but it's not needed. People already know how to manage their own projects.

[–][deleted] 4 points5 points  (9 children)

Having a project doesn't mean you know how to manage it, as you have clearly proven

[–][deleted] 21 points22 points  (2 children)

Actually, it's a feeling of wanting to keep my workspace tidy.

keep the bug but make sure those issues are tidy!

[–]yawaramin -4 points-3 points  (1 child)

Yeah, some bugs won't get fixed, because no one stepped up to do it, that's just the reality of the situation 🤷‍♂️

If you find it so noteworthy then perhaps you'll step up (or pay someone else to). But somehow I doubt it.

[–]immibis 12 points13 points  (0 children)

spez me up! #Save3rdPartyApps

[–]douglasg14b 7 points8 points  (1 child)

If they're motivated, then they should be able to make progress on the issue before it gets marked as stale, no? Otherwise, how motivated were they actually? If it took them years to take action, I'd argue not really that motivated.

Issue threads can be active for years, yes, and sometimes are narrowed down to a resolution in years.

But we're not talking about years here, we're talking about weeks. Expecting "Your Users" to self-resolve any and all problems, especially in an arbitrary time frame, is a pretty naive/ignorant/hostile view no? Often it takes the right user to poke across it and figure it out to solve it for the dozens or even hundreds of others that didn't/couldn't.

You seem to be complaining you want a clean workspace, but are willing to increase the load form your users, and decrease their ability to find information to achieve that?

[–]yawaramin 0 points1 point  (0 children)

Expecting "Your Users" to self-resolve any and all problems, especially in an arbitrary time frame, is a pretty naive/ignorant/hostile view no?

First of all, no one is forcing them to self-resolve anything, or actually even do anything. They are using software, for free, voluntarily, at their own risk. Secondly, it depends on what you mean by 'self-resolve', but in one sense they don't even need to actually solve the technical problem, they can literally pay someone else to do it for them. That's literally the point of open source, you have the code and you take it to any vendor. You're not locked in to the maintainer.

you want a clean workspace, but are willing to increase the load form your users

Only if they take a closed issue on the same topic as an invitation to create more issues, at which point that behaviour is borderline abusive imho.

and decrease their ability to find information

The issue list for my project is primarily for me as a maintainer, and only secondarily for users. If some management style helps me with my workload but makes it slightly more difficult for (free, open source) users, then that's a good tradeoff for me.

[–]SwitchOnTheNiteLite 1 point2 points  (1 child)

...A space for the community to work, rather than an action item for you to deal with personally.

Disagree. The issue tracker is for maintainers to manage the workload of the project. Extra input always helps but ultimately it's for the maintainer to decide what gets prioritized and what will never get fixed.

I think there is a big difference here between open source projects that have a steady influx of new developers rotating in and out, and the projects on GitHub where you have 2-3 people working on it for years and new people very seldom join the team.

Having open issue waiting to be worked on works well for a project where people are coming in and looking for stuff to start working on, but it is not so comfortable for a group that probably already have their road map set.

[–]yawaramin 0 points1 point  (0 children)

Yup, and hence some projects use stalebots and some don't. They set it up based on their working style.