If those issues are still a problem nobody will find them, they'll make new issues and lose all the previous history, unless the UI is designed to support automatically suggesting reopening an old issue instead.

A middle-ground might be to leave open the issues with recent activity, with the idea being that at least the ones that are affecting people the most are not swept under the rug.

There's a crucial question here that I find not enough people ask themselves: does that actually matter? And if yes, why? What, specifically, is the material problem caused by this situation?

It often feels like people are just chasing 'inbox zero', under the assumption that "0 open issues == good", without any actual material problem being solved in the process.

(Github probably isn't helping here, with their undeservedly prominent placement of the open issue count driving this sort of behaviour...)

Whether any given ticket is being looked at can change over time. Closing it is a way to drastically reduce the likelihood that it is being looked at. As a user, I see no good reason why that should be done, in particular when it is applied across the board without considering the individual issue.

As a user you obviously see no good reason for that. As maintainers having more bugs open than will ever be worked on (e.g. because no one will put up the legwork), serves no good purpose.

PS: individually considering each of 100s of issues takes time and mind share, that can better be invested elsewhere.

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.

So yes, 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, you 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. Here is a helpful tutorial on doing that on GitHub: [0]

The rest of the post you replied to remains unaddressed by your 14-word-long opinion. Please provide a more substantial reply to this one if you are having a serious conversation.

[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).