All kinds of open source projects do this too. It's really annoying. It's one thing if the authors actually try and fail to verify the bug, but these days it seems like most projects just close "stale" bugs as a matter of course. This is equivalent to assuming that any given bug is automatically fixed after X amount of time, which is pretty absurd.
It's rather unreasonable to be annoyed. The maintainers may have entirely different priorities, which is fine. They're also likely being spammed with low-effort bug reports (not yours necessarily but from others).
The great thing about open source projects you can just fix the bug yourself and submit a PR, or fork the whole project if the maintainers won't merge your changes. If you don't have the time or skills yourself then you can even pay a contractor to do it for you.
I disagree. If you discover that a bug that makes an open source library unusable to you, after spending time on learning and using that library, and the authors close the bug as a wontfix, I think being annoyed is quite reasonable, even expected.
If that type of thing annoys you then you should restrict your use of open source projects to those backed by corporations with a paid support business model.
It's open source software. If you discover the bug, have written a failing test that demonstrates it, and a proposed solution to it, then maybe you can be annoyed when the authors close it as wontfix.
Otherwise OSS is pretty much as-is, where-is, with the exception of very widely used and corporately supported projects.
If the maintainer merely doesn't fix the bug, then yes. If they close the bug report so it gets lost and other contributors are discouraged from working on it, then no.
Closed reports are not lost, they are still searchable/linkable, they are just not in the list of work to do.
This is entirely up to the maintainer, who puts in the work and gives up their time/money to do so. If you want to be in charge on a given repo, put in the work and become a real contributor, if not accept the rules the maintainers choose.
Dupe reports are a signal all by themselves, that's really not harmful, nor does something being closed implied solved.
You shouldn't presume to know what is best for an open source maintainer of any given project - projects vary, reports vary in quality, and the job of maintenance is not an easy one.
It is not about "priorities". Putting work into writing bug is utterly useless, because if the maintainer does not fix it in 2 months, the bug will be closed as stale. I am actually fine with open source project maintainer to prioritize stuff and hey, maybe that bug will be fixed in 6 months when they have time. But I am not fine being told "we did not had time for 2 moths, therefore we are closing your bug" as is standard on github now.
Do not throw the ball back with "this happens because bugs are not well written". Stalebot closes bug regardless of whether they are well written and ensures no one will put effort into writing another well written bug again.
Is that a serious question? It works like any contract programming gig. You give the contractor money and in exchange they give you code (including copyright assignment). You can go through a freelancer site like Upwork if you don't know an appropriate contractor yourself.
> Adding filters so that developers only look at actionable tickets would be much more sane.
That's a reasonable approach, but I don't understand how it's any more or less sane than autoclosing them with a stale label.
Whether these sorts of bugs are "open but stale" or "closed because stale" seems like it depends on whether the project defines "closed" as "no work planned" or "fixed", which both seem valid.
Either way these bugs will be hidden from developer dashboards but still available in the database so there's no practical difference, you just need to make sure everyone is on the same page about the meaning of "closed".
