Closed doesn't mean resolved, it means closed. Closing issues just shifts them to another tab, doesn't remove them entirely. What you propose, a filter to hide these, is exactly what has been done just through the official open/closed filters.
On GitHub, it is true that the Issues search shows only open issues by default, but I think users are quite aware that they may need to search for closed issues, especially since it's unlikely they are on the absolute latest version of a package, especially when debugging problems in production. Additionally, some projects close issues once the mainline has addressed them even if the fix isn't in a released version.
GitHub does not render closed issues as struck through, and it does not by default lock conversations on closed issues.
EDIT: I am not taking a side on whether or not it's a good idea to do this sort of "bankruptcy" mass close.
I think users are quite unaware, given how we have no evidence they're quite aware, and the normal thought process is "closed == resolved" (fixed, wontfix, etc)
A normal thought process would be to close individual bugs as you confirm they aren't present in the new version – the end user already bore the burden of writing a bug report, and you owe it to them to actually determine if the issue is resolved before closing, even if the resolution is "wontfix".
Closing bug reports without actually caring about whether they were resolved is giving the finger to your users. Why even have bug reports at that point? As far as users are concerned, you'll just close any new ones for some new reason anyways, based on your track record.
Now: new version, all bugs closed. Next: new name, all bugs closed. Then: new logo, all bugs closed. After all, you close whatever bugs you want, whenever you want, for whatever arbitrary reason you want. And why not? It's your repo. Why does it matter if the bugs are fixed or not when you close 'em? You got a new thing! Close all bugs!
Stop right there. It's an open source project. You owe the users absolutely nothing.
Saying things that conflict with that disclaimer does indeed chip away at the effect the disclaimer has on your responsibility.
Stop right there. When you ask people for feedback, be it 1-on-1s or bug reports, ignoring the feedback is ruder than never having asked in the first place.
If you decided to ask for feedback, and they're kind enough to take time out of their day and spend their efforts to help you out in the way you asked them to help you out, then yes, you DO owe it to the provider to not then tell them to bugger off with said feedback.
If you were going to do that, you should have disabled bug reports from users, instead of asking users to help you by providing feedback. Here is a helpful tutorial on doing that on GitHub: [0]
[0]: https://docs.github.com/en/repositories/managing-your-reposi...
And that is a general issue with the maintainers not understanding what they're doing, or not understanding how issue trackers work.
If you close an issue that is still present in the current release, then you're doing it wrong - with one exception. If it is in fact functioning as intended and the issue was just a misunderstanding, then explaining that and closing the issue makes sense. (But even then you might want to update the docs or helptext or something to prevent future misunderstanding, if it's confusing enough.)
Closing an issue just because you don't feel like looking at it today just means that someone else will open a new issue tomorrow to report the same thing. And any history, workarounds, steps to replicate, etc. in the old issue will be lost/disconnected. That's not doing anyone a favor.
> And that is a general issue with the maintainers not understanding what they're doing, or not understanding how issue trackers work.
> If you close an issue that is still present in the current release, then you're doing it wrong - with one exception. If it is in fact functioning as intended and the issue was just a misunderstanding, then explaining that and closing the issue makes sense. (But even then you might want to update the docs or helptext or something to prevent future misunderstanding, if it's confusing enough.)
The concept of an issue tracker was not bequeathed to us from on high. There is no single "right" way to do it, nor can you (context free) tell someone they're doing it "wrong".
Some people use issue trackers to inventorize bugs in current releases. Some people use them as a dev's todo list. If you do the latter, closing the issue once you've implemented the fix is perfectly reasonable.
> Closing an issue just because you don't feel like looking at it today just means that someone else will open a new issue tomorrow to report the same thing. And any history, workarounds, steps to replicate, etc. in the old issue will be lost/disconnected. That's not doing anyone a favor.
It feels like it's doing the developer a favour.
I've never actually seen a project only close issues when they make a release. Rather they make a new release when there are enough resolved issues or new feature PRs. Though of course they can do whatever they want. There are a lot of projects where it is known that the latest git main should be used and the latest actual binary release is from years ago.
Personally I am not going to assume that people are competent enough to check the open issues but too lazy to check the closed issues, or simply too dumb to understand a comment like "closed because I am not going to fix this".
If I won't be working on it, if no one is working on it, I won't leave the bug open.
Either someone shows up and decides to put up the legwork or it gets closed, even if it doesn't cross the threshold of wontfix (i.e. I won't accept a fix).