Hacker News Reader

I mark bugs, security-related issues, and planned features with appropriate labels, and the stale bot ignores those: https://github.com/geerlingguy/ansible-role-docker/blob/mast...

Not all maintainers do the same. And some even _lock issues_, which I hate, because even closed issues can have a very fruitful discussion long after the issue was originally posted.

Then you are, in my humble opinion, doing it exactly right :-) (apart from going all-in and just never closing anything, but yours is a very good middle ground)

> even closed issues can have a very fruitful discussion long after the issue was originally posted

100% agree! In some occasions I've learned a lot from reading long related conversations in a bug report that had been closed or resolved long since.

TIL that my hatred of stale bot is somewhat misplaced, because it seems that it can be configured in a way I think is a lot more acceptable.

Shame when it's set to be aggressive, it can be a serious hindrance. Issues almost act like a user forum, and can be super useful even if the maintainer doesn't want to put energy into that particular issue. I've found some really helpful work-arounds in "stale" issues.

If you don't like how some open-source library is managed, then exercise your freedom to fork it. Anyone who then claims that they don't have the time or energy to maintain such a fork cannot also reasonably expect anyone else to spend their own time and energy maintaining it for them.

It isn't more work for the maintainer to _not_ close issues purely based on time. This argument has been repeated often. And with the prevalence of lazily-used stale bots, it's not feasible for anyone to make all the forks necessary.

Discussion can eventually lead to a shift, repeating this argument can't.

> It isn't more work for the maintainer to _not_ close issues purely based on time

This overlooks the emotional burden of having a large, unbounded backlog.

When I see that I have a missed call, I feel an obligation to call that person back. When I see that I have a text, or a DM, or an email, I feel an obligation to respond. Individually these are all minor obligations, but in aggregate they eventually coalesce into anxiety. PRs, too, get thrown onto this pile.

Burnout is a self-imposed "boiling the frog slowly" scenario caused by gradually taking on more responsibility than you can successfully deal with. Realistic ways to prevent burnout are by either aggressively preventing new obligations from being thrown onto the pile, or by periodically defaulting on obligations and resetting the pile entirely. It appears to me that the stale bot is an instance of the latter. An instance of the former would be to just outright forbid PRs entirely.

And if anyone thinks that they have the mental fortitude to handle an ever-growing and unbounded pile of obligations, then that only reiterates the call for them to fork these projects and accept the burden personally.

I've solved that problem by being one of those people who never calls back or checks voicemail. At some point, I've got 75 e-mails to mark as read and delete today.

A bug report is an observation about a particular version. If nobody bothers to test newer versions, you don't know if it's real. The more the code changes, the less likely the behavior is still there.

Now, granted, it's likely that if nobody did anything then it's still broken, but it's still the case that a bug database, considered as documentation, gradually becomes outdated and increasingly misleading if not maintained.

Stale bugs are still in the database and you can still query them. Nothing is lost. The question is how relevant old history is when it comes up in search results?

Maybe querying on open bugs only is the wrong default? Stale bugs should probably be included but with much decreased rank.

I agree with this, too. Which opens up a nice point of discussion: closing stale bugs is bad because it sweeps the issue under the rug; but closing them is good in case the context and source code around the issue has changed a lot.

In this case I'm not sure what's the best solution. I have suffered myself finding an open bug but so old that it didn't really apply any more. However in those cases, it has happened that attracting attention from a dev, or just testing by myself, has driven the conversation into quickly realizing that the issue didn't apply any more with current state of the source code...

Maybe it's a good idea having the feature of specifying which version the bug was reported against. GitHub doesn't have this, but I've seen it in some other bug trackers.

In an ideal world, someone would go over the open bugs on some timeline and mark them as no longer an issue, still an issue, don't know, or won't fix. An easy timeline to specify would be take a look 3 months after last activity and double the wait every time.

Of course, that takes time and effort and some bugs are harder to evaluate than others.

Typically this gets bounced back to the person who reported the bug and if they don’t care (and why should they if they moved on) then nobody does it.

Overwhelming majority of closw as stale bugs are existing bugs no one commented about last X months. They did not magically went away.

They are still there, exactly as described.

Your latter point doesn't make a lot of sense to me. I write and maintain open source software because I enjoy seeing people use it. For me, not giving a shit about it means not working on it at all. It seems like it's as easy as keeping "no FITNESS for a PARTICULAR PURPOSE" as a mental mantra but in reality that just doesn't work for me. And I bet I'm not so different from most foss maintainers.

> it's as easy as keeping "no FITNESS for a PARTICULAR PURPOSE" as a mental mantra

It definitely is. Of course OSS authors and maintainers want to see people using and enjoying it, but nothing is black or white.

What you really mean is that you want people using and enjoying your software within the limits of time and abilities that you can employ on it without it affecting your mental health.

Some people are worse than others at finding out about this latter part, and as a consequence they suffer.

My point of view is that if you don't care as default state, then you put work into actually caring, when you get to your limit you'll be able to very easily see that you cannot contribute any more hours today, because you're almost depleted how much you actually care. Thus avoid crossing that thin line that is burnout and all mental health issues that come with it.

I.e., be in a defensive mental state. Ironically, it will make you work happier and over a longer period of time, which ends up being positive for the health of the project itself.

> It definitely is

I just told you that for me, it's not. Repeating your view isn't adding anything. Restating it doesn't make it so. I understood you the first time.

> My point of view is that if you don't care as default state, then you put work into actually caring, when you get to your limit you'll be able to very easily see that you cannot contribute any more hours today, because you're almost depleted how much you actually care. Thus avoid crossing that thin line that is burnout and all mental health issues that come with it.

I completely believe that's how the mental process works for you. That's not how it works for me. If I detach myself from the project enough to not let it affect my mental state then I do zero work on that project.

I see. Not being able to detach your mental process from an overburdened project probably means that you are more prone to suffer the kind of issues discussed every time this topic is brought up. Caution is advised, I guess.

You might be able to perfectly handle your OSS projects despite of this tendency, you probably have your own complementary techniques (like limiting the number of simultaneously accepted PRs at any given time? I'd be interested if you want to share any), or if a bad wave of burden arrives one day, you might end up burning out and either throwing the towel or growing a thicker skin. Hopefully the latter!

If I encounter a bug in a thread closed by a stalebot, my natural conclusion is that the developers have no intention or desire to ever fix the bug. This usually leads me to searching for alternatives rather than wasting my time re-reporting it.

"See, the issue is there. Don't have time? Ok leave the issue open, it acts as a documentation about, well, that there is an unsolved issue."

I think this is really important. In some projects, the number of open issues is always zero. Most people see this as a good thing. I think it is not. we need projects where there are hundreds of open issues and these issues are visible. it is important to solve problems if they want to be followed clearly. I think it is a very important issue to be able to follow up the problems clearly.

Absolutely. If nothing else, the issue report establishes a findable, centralized location for users to share workarounds with each other.