[layer8]

This is not accurate. When searching for issues, users won’t find closed issues by default. When issues are linked, closed issues are rendered differently (struck through). You can’t comment on them anymore without reopening them, and reopening them is often discouraged or not enabled at all. It is a drastically different state.

[rezonant]

Either you are thinking of other project management tools or assuming that some of the "stale issue locking" and automated issue management tools that some larger projects use are default.

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.

[Falkon1313]

> Additionally, some projects close issues once the mainline has addressed them even if the fix isn't in a released version.

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.

[growse]

> > Additionally, some projects close issues once the mainline has addressed them even if the fix isn't in a released version.

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

[dizhn]

In my experience closed issues are usually closed with an associated PR and the issue it fixes gets merged into main/master.

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.

[rezonant]

I keep issues open until a release resolves them for all my open source projects. It helps to prevent duplicates, helps me maintain good release notes, and ensures the open issue list is a more honest description of the software you get when you fetch it via your package manager.

[ImPostingOnHN]

> 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

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!

[ahtihn]

> and you owe it to them

Stop right there. It's an open source project. You owe the users absolutely nothing.

[ImPostingOnHN]

> You owe the users absolutely nothing.

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

[cwillu]

If you perform marketing and/or evangelism for your project, it's not at all obvious that you owe your users nothing.

[growse]

The act of marketing software doesn't invalidate the license, which often explicitly states that the software comes as-is and free from warranty / support.

[caturopath]

Offering an as-is disclaimer doesn't rid someone of all social, moral, or legal responsibility.

Saying things that conflict with that disclaimer does indeed chip away at the effect the disclaimer has on your responsibility.

[Dah00n]

Sure you do. Anyone asking for feedback owe to respond on said feedback.

[blitzar]

Allowing feedback != Asking for feedback

[ImPostingOnHN]

opening your feedback system to users == asking users for feedback

[rezonant]

I agree with most of this, but I do think that other than the worst of the users (which admittedly are much more visible than the better ones) do in fact understand how to navigate closed issues.

[rimunroe]

Wait what? Since when can’t you respond on a closed issue without reopening it? I’ve partaken in lengthy discussions on closed issues without them reopening. Obviously you can’t reply to locked issues of course, but that’s a separate thing.

[eddythompson80]

most of that is not really true. where are closed issues rendered struck through? It's up to the repo to lock closed issues or not, and it doesn't appear this repo did that.

[blitzar]

In my project a ticket that is open / closed / tagged timbuktu means whatever I want it to mean.

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