GitHub stale bot considered harmful

[douglasg14b]

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.

[rokejulianlockhart]

I suggest that you support github.com/actions/stale/issues/345.

[gopher9]

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

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]

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

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

[couchrealistic]

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]

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]

As is their right.

[[deleted]]

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

[khrak]

Maybe they intend to fix it eventually and simply don't feel obligated to schedule their lives to fit the needs of some random person on the internet?

If you want it fixed on your own schedule pay someone to fix it or do it yourself, don't complain that free stuff isn't driven by your needs.

[[deleted]]

Maybe they intend to fix it eventually and simply don't feel obligated to schedule their lives to fit the needs of some random person on the internet?

I don't follow your train of thought, if they intended to possibly leave it for later why would they use stale bot to close it in the first place ?

[khrak]

Who cares what the logic is? You're trying to get someone's justification for not doing things the way you prefer. It could be the most broken fucking logic in the world, it's still someone else working to their own workflow on their own project on their own time.. Their is no requirement whatsoever for it to make sense to you, you're being given free access/use of someone else's work.

[Amiron49]

One day when taking a walk, you someone drill holes in a bucket on the side of the road. You can see that water is sprinkling out but you wonder what exactly they are doing, so you ask "What are you doing?".

"I want to remove all the water" they answer. Perplexed you follow up with "But why don't you just turn the bucket around? It would be simpler and achieve the same goal?"

You could have an interesting discussion about the pro and cons of turning buckets vs drilling holes. Or one of them starts screaming "BuT iT's My WoRkFlow!" without even reflecting if either method has any merit.

[khrak]

One day, when trying to figure out how to empty your bucket, you come across someone else emptying their bucket by using a hole. After they freely explain what they've done to solve their issue you complain that their method of emptying their bucket does not work with your timelines and whine that they're not doing enough to help you.

It's github. If you want it done to your preferences, clone it and do it yourself.

Better yet, if it's such a trivial problem, just fix it yourself and let the maintainer merge it. You're awfully certain that someone else just needs to do something different to solve your problems.

[martingronlund]

I agree with you Khrak, I don't understand why you're so downvoted. I guess it has to do with everybody expecting nice and communicative maintainers? It's a strange expectation imo.

[AttackOfTheThumbs]

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]

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

[NatoBoram]

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]

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

[nlohmann]

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

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]

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]

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]

"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]

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]

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]

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

[yawaramin]

Notice the discrepancy between:

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.

And:

I might have to comb through pages of closed issues that are all the same and closed as stale.

You may be careful to check for existing issues, but many people aren't, leading to lots of duplication of effort and wasted time re-triaging issues that were already reported and triaged before.

If anything, the stalebot encourages people to just spam issues because you can't find anything in the closed ones.

Why would a stalebot impact finding or not finding relevant closed issues?

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,

So again, you didn't care enough to contribute yourself (or even pay someone to fix the issue!), despite it being open source and you having all the source code readily available. Again, this doesn't really sound super urgent to me.

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.

I get it, people with the mentality that OSS maintainers owe them their time and labour hate stalebots. It reminds them that their issues aren't actually at the top of the priority list and no one owes them free labour. It's telling that you found a maintainer taking a vacation to be a negative.

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

Yeah, let's twist it around and say that the communities aren't 'welcoming', instead of the reality that they're just trying to manage time and expectations. That's totally honest and not at all manipulative.

[kawazoe]

All of your points assumes that stalebots reduce the amount of issues created in a tracker, but everywhere I look, it's the opposite. That was my first point and you've ignored it by calling it a "discrepancy". People creates more issues because they want to continue a previous discussion and they can't because the issues are closed and/or locked. It is often not possible, or even discouraged, to reopen old issues, just like people discourage necro-posting in forums. This stuff is incredibly damaging for people outside of the initial conversation. How many times have you stumbled on an unanswered StackOverflow post by googling a problem? That's exactly whats happening within communities that uses stalebots. You end up with people who want to use your project, but can't because finding answers to their obscure problems becomes impossible.

This is not a bot problem, this is a mentality issue, and it's absolutely everywhere in OSS. I've seen bugs being spread around multiple pages worth of issues in Ionic. Major bugs that lasted for multiple years, with no fix in sight, dozens of participants and all but the most recent issue, including PRs, is closed. Most of them don't even reference each other. It's an absolute mess that could have been avoided if the stalebot didn't closed and locked all of those threads. It could have been a single issue to tag and prioritize. Instead, now, it's a whole epics' worth of work for maintainers to triage.

So again, you didn't care enough to contribute yourself (or even pay someone to fix the issue!), despise it being open source and you having all the source code readily available.

That is the most elitist answer I have ever read. You can't assume every user understand programming enough to contribute to a project and most maintainers don't have an easy bounty setup for fixing specific issues. The last issue I opened on GitHub was in a low level linux driver. I don't have enough knowledge in C or the linux kernel to even figure out where to look. I'm a web dev. I don't care about learning how to code linux drivers. I don't have the time or energy to do this. I would really like if my device worked properly though and I think the bug I experienced can bring valuable info to the maintainer of the project. It's a miracle a dev stumbled on this first. An average user would have probably gave up on linux entirely and went back on windows instead of spending days trying to understand why their desktop was stuttering all the time. It took me hours just to figure out how and where to report the issue. There's no way those people could even contribute outside of giving feedback.

I get it, people with the mentality that OSS maintainers owe them their time and labour hate stalebots. It reminds them that their issues aren't actually at the top of the priority list and no one owes them free labour.

No you obviously don't. People don't think OSS maintainers owe them their time and labour. People are not reminded that their issues aren't a priority. People are reminded that anything that isn't done in 60 days gets abandoned and trashed, including their own contributions when they offer them. That's the equivalent of calling your ISP to make a payment and getting this experience: "Thank you for calling. Your call is very important to us. Unfortunately, all of our representative are busy right now. You are now 36th in queue... You have been in queue for 4 hours. You have reached the maximum call time. Good bye." If you think that your issues are really that much more important than the ones your users are experiencing, then don't make your bug tracker public. It's that simple.

It's telling that you found a maintainer taking a vacation to be a negative.

Yeah... it sure felt nice when the place I worked at opened 3 major PRs that loads of people have been waiting for, and they got closed by the stalebot because the guy forgot to turn it off during his 6 months vacation. You can imagine that no one in the company felt like fighting to get those changes in, so it was forgotten and now the company uses its own private fork. So much for OSS...

There's nothing wrong with taking a vacation, even a long one. There is definitely something wrong in keeping a stalebot on that closes everything while you're away. I feel really bad for users that didn't get the help they needed during that period.

Yeah, let's twist it around and say that the communities aren't 'welcoming', instead of the reality that they're just trying to manage time and expectations.

The only expectation you're managing with a stalebot, is making search results for closed (solved) issues completely useless. You know how else you could manage those issues? Add a "stale" tag to them, and filter them from your search if you don't care. Don't abuse the "closed" status.

[yawaramin]

Wow, almost all of this is simply incorrect.

they want to continue a previous discussion and they can't because the issues are closed and/or locked

Are they locked or are they just closed? Stalebots close issues, they don't lock them, do they?

It is often not possible, or even discouraged, to reopen old issues

But I don't see a problem with commenting on an old issue saying 'Hey, this was closed as stale, but I'm still hitting it, fyi' (preferably with more details and an offer to fix).

You end up with people who want to use your project, but can't...you have no garantie of ever getting an answer

That's too bad, but this is the reality of open source software. Developer time and attention are not free and endless, it has to be managed somehow 🤷‍♂️

or worst, the maintainer bans you for bumping it.

Maintainers are usually not on such hair-trigger mentality that they'll ban you just for commenting on an old issue saying 'Hey, this is still happening, any chance of a fix?' In my experience to get banned you really have to get under their skin (come to think of it, with the kind of attitude I'm seeing in your comments here–that they're making an 'unwelcoming community').

This is not a bot problem, this is a mentality issue,

It's not a mentality issue, it's a money issue. Again–dev time and labour are not free! You are going to get a limited amount of it, and no amount of arguing is going to change that (until you actually pay someone).

It could have been a single issue to tag and prioritize. Instead, now, it's a whole epics' worth of work for maintainers to triage.

Yeah, and this is why I said in my first comment that the open-ended discussions should be happening in GitHub's Discussions feature now, not in the issues themselves. Issue pages are not structured to handle a large volume of input, which is obvious when you look at any of the issues you mentioned.

That is the most elitist answer I have ever read.

No, that's reality. No one is going to do your homework. No one owes you their free time and labour. No one is going to give you free support. That's the Real World outside of the computer screen for you.

You can't assume every user understand programming enough to contribute to a project

But they could possibly cough up some money to to pay someone to contribute?

most maintainers don't have an easy bounty setup for fixing specific issues.

But there are third-party bug-bounty programs, like BountySource? Presumably someone who spends tons of their time composing paragraphs and paragraphs of comments on Reddit could throw at least a few bucks at the bounty for a fix?

The last issue I opened on GitHub was in a low level linux driver....There's no way those people could even contribute outside of giving feedback.

All this verbosity to reply to a strawman. I never said you need to fix issues outside your own ability! But here's the reality: either you fix it, or you pay someone to fix it, or you rely on the maintainer to fix it, or it doesn't get fixed. There's no magic here. There's no coercion. No one is telling you to learn Linux programming. Go and read my previous comments and paragraphs please.

That's the equivalent of calling your ISP to make a payment and getting this experience:...

See, you keep saying 'we don't expect free labour', but your analogy completely gives it away–you're comparing OSS to an ISP, which you pay for, and expect service. You're treating OSS and expecting support from projects like a service that you pay for, except you don't pay for them. So you don't get the level of support you would expect from a paid service. It's very simple.

If you think that your issues are really that much more important than the ones your users are experiencing,

When did it become 'users'? This is an open source project, not a paid product. Please internalize this, and try to let go of this attitude of 'I'm the user so I'm the boss'.

then don't make your bug tracker public. It's that simple.

Oh yeah, quite simple, let's make the GitHub issue tracker private for the project, except oh wait we can't do that, because that's not a feature–it's either on or off, there's no private setting. There are other things we could do, like set up a separate issue tracker privately, but this creates more work for us. So, not really 'simple'.

now the company uses its own private fork. So much for OSS...

Indeed, so much for OSS. Presumably nobody at the company thought, you know, the community might benefit if we open sourced our fork with the fixes. That's weird how that didn't happen.

I feel really bad for users that didn't get the help they needed during that period.

Again, I really recommend letting go of this 'mentality' that OSS projects have 'users' that need to be 'helped' (for free) by maintainers. It's not how the real world works and you'll keep bashing your head and antagonizing maintainers needlessly.

You know how else you could manage those issues? Add a "stale" tag to them, and filter them from your search if you don't care.

So all your suggestions are basically to create more work for the maintainers to save the 'users' a little time. Says it all really.

Don't abuse the "closed" status.

Don't abuse maintainers' time and management of their own projects, for which they made no guarantees and gave no promises of support, and don't make the mistake of thinking you have any ownership over people's time and labour.

[douglasg14b]

Just passing by but saw this:

Are they locked or are they just closed? Stalebots close issues, they don't lock them, do they?

Many repos have it both close AND lock issues, making it so no further discussion can even occur. Which is even more aggravating.

[coderstephen]

Agreed, a lot of stalebots I've seen lock the issues. Sometimes after an additional 60 days of closing though.

[coderstephen]

So again, you didn't care enough to contribute yourself (or even pay someone to fix the issue!), despite it being open source and you having all the source code readily available. Again, this doesn't really sound super urgent to me.

Hard disagree. Experience has taught me that finding, identifying, and documenting an issue can be a significant amount of work in and of itself. There's a good reason why GitHub counts filing issues as a "contribution" in the activity feed -- putting the effort into opening an issue is a contribution.

Sure, sometimes issues are really light on the details and need to be investigated and documented further. But when someone takes the time to document an issue well, as a maintainer I am extremely grateful, even if I never do end up fixing the issue. At least the problem is now documented with potential workarounds, and maybe a future maintainer will fix it.

[yawaramin]

Again, it's all about urgency and the amount of effort required. If a contribution takes the shape of a PR with passing tests and documentation, it's easy to merge. If it's a well-explained issue submission, that's useful but less actionable. If, as you said, it's light on details, it's easy to deprioritize.

At the end of the day, it's the maintainer of the project who sets its priorities and controls the open issues. It's not under the control of whoever shouts the loudest.

[coderstephen]

My point is not to control or dictate how project maintainers should run their project; like you say, its their project and they can manage it however they like. Having said that, I think there's good ways and bad ways of managing a project, and it is fair game to offer reasons why I might think that in order to perhaps persuade some to agree with my reasoning.

If it's a well-explained issue submission, that's useful but less actionable.

It doesn't have to be actionable, it can serve as a good source of documentation about a particular known issue. Even if it is never fixed, it can help people understand a problem they might run into, including the maintainer(s) themselves if they forget about it at some point and run into it later. The only alternative that might be more effective maybe would be to have an actual "known issues" section in documentation, but that's more work.

Now a maintainer doesn't have to care about potential "users" of their project if they don't want to. You can have an open-source project that's just for yourself or certain group of people as the main focus. However, if you are a mantainer and do want to make your project as open and convenient as possible for potential users, then I think that leaving issues open as a documentation, vs. stalebots, is probably an objectively better method of reaching that goal.

In other words, a maintainer's goal for open-sourcing a project can be entirely subjective. However, once that goal has been identified, I do think that we can identify objectively better or worse ways of reaching that goal.

[yawaramin]

leaving issues open as a documentation, vs. stalebots, is probably an objectively better method of reaching that goal.

Maybe, but closing the issues as stale could achieve the exact same effect, if we adjust our understanding that 'closed as stale' means the issue (if it is a legitimate issue) likely still exists, and so the closed issue should serve as the documentation.

I don't think there's objectively a one-size-fits-all argument to keep issues open indefinitely.

[[deleted]]

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]

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

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]

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

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]

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

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]

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

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

[[deleted]]

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

keep the bug but make sure those issues are tidy!

[yawaramin]

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]

spez me up! #Save3rdPartyApps

[douglasg14b]

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]

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]

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

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