Agreed. The bug report was one reporter and a maintainer discussing a bug for 2 months back in 2015, and at the end the maintainer says he believes he’d fixed it. Then no more messages. After 5 years of no complaints after a likely fix, closing it is very, very reasonable.

I'm kind of on the fence for these (in general, not specific to this ticket).

Assuming the STR is clear, is it the original reporter's responsibility, or the developer's, to confirm if a bug is fixed or not?

IMO, It is the user responsibility to make a reproducible bug (to become a failing test). From there on it is the developer responsibility to fix it (make it a passing test)

Absolutely. If there is nothing new and a bug is still there, there is simply nothing to add to the bug report. Too often now bugs get closed automatically for "inactivity" after a short period. Should users come back every months to "ping" the thread ? Some bugs last for years, they'd sooner be blocked for spamming. It's just Goodhart's law in action, a cheap way to reduce the bug report count.

No other approach is sustainable.

Really? You think that expecting a user who submitted a bug report five years earlier to still have patience to interact with it is sustainable?

Not five year. Two months went from the OP in September 2015 to the final dev message in November 2015, during which the OP and the dev were communicating regularly. It was the OP who didn't respond after the dev mentioned that he believes that he fixed all the outstanding issues.

It was five years later that someone came along and closed the bug.

I would estimate the chance of a user coming back to close a bug at near zero, even after only two months.

Indeed. As a fellow maintainer I will manually replicate the error the user reports, write an test to around the failing function, then fix said function.

After that I’m usually satisfied the bug has been fixed. So I will link the git commit hash of the fix to the bug report and ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.”

That is the only way I’ve found to manage projects because you either end up closing tickets prematurely and miss bugs, or you end up with tickets open for fixed issues that take time and additional mental overhead to filter out (both of which are a scarce resource when you’re trying to balance open source maintenance with a full time job and a family).

Two weeks might not seem long but I’m always happy to reopen issues. However if users really feel that hard done by this approach then they’re welcome to submit a pull request instead. Or even fork my project and maintain that they way they feel it should be done. Maybe they’ll have more free time than me to filter through historic issues that are now fixed but not closed between their personal lives and coding time.

> ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.”

This tacitly embraces the bugtracker-as-helpdesk/CRM mindset, i.e., the GitHub approach, which is what leads to things getting so chaotic and unwieldy in the first place. It's right in the language—focusing on "their" issue. Both maintainers and users need to approach the bugracker by recognizing that the scope of any given bug report is the bug, and by extension the project, not the bug reporter or maintainer. By the time a bug is being closed, a maintainer should know (at least with some level of confidence—but allowing for them to be wrong) whether the bug is fixed or not—because it should be well-defined. If the maintainer is not able to do this with confidence, it indicates a failure in the practices for handling bugs—and possibly (or "likely", in the case of a typical project hosted on GitHub) muddled scope.

It may be the case that from the user perspective, they're still experiencing some issue, but this doesn't call for the bug being reopened to handle it. Remember, it's not theirs, it's the bug's! If the last report led to a real bug being identified, and it really was fixed, then leave it closed and figure out if it isn't the case that they misidentified the source of the discomfort they were experiencing, and if so, have them attempt to articulate it, then open a new bug for that. Otherwise, you're just treating your bug tracker like a message board but splattering it with state changes of what amounts to your personal TODO list—where "open" and "closed" correspond to whether you've decided you're finished with it or not. Remember not to think of the bug tracker as yours either! It belongs to the project and its bugs. Think of the software as a non-human entity and you as a scientist and its designated caretaker. It's best to think of the bug reporter as a scientist, too—and the elevated expectations and responsibility that comes with it.

You're focusing too much on correctness. Bug reports are almost never because a user has identified incorrect behavior, they are because the user has identified unpleasant behavior. The maintainer then takes that reported unpleasantness and decides whether it's a bug or a feature. If it's a bug then the maintainer, usually implicitly, updates the program specification such that the unpleasant behavior is now incorrect, perhaps by writing a test, and then corrects the incorrect behavior. But since the primary motivator is actually the user's reported unpleasant behavior, it makes sense to check that the now correct software also behaves pleasantly for the reporting user. And since pleased users may well just be using the software instead of following up in the bug tracker, it makes sense to close those issues with the proviso that displeased users are welcome to reopen them.

It's an observable truth that if you want people to use your software, it's necessary to prioritize pleasantness. It's also practically a logical necessity, unless your user community is comprised of individuals who enjoy being displeased and otherwise frustrated.

There are multiple types of issues. You’re describing a bug in a very pure sense. But often the most important issues are customer issues where they are blocked and need help. Then it is less about the big that you’re tracking and more about this customers experience. The resolution to their issue might not even be in your products code, but we still track it until the customer is unblocked to use our product.

Personally if a bug report does not get a reply in two months I'm probably not using it anymore. Collaborating to these kinds of projects is extremely frustrating. Why will I spend my time debugging and implementing features when issues and PR are promptly ignored or closed? Is my time a joke?

Recognising the orignal bug opener's name, Markus Triska, I know he's on HN. I checked his username to see if he's been active recently and, well, see for yourself: https://news.ycombinator.com/threads?id=triska

Maybe if the bug is important, someone else will reply to confirm? That could be a reasonable line of thinking.

Yea, if a bug has been open without further discussion for 5 years then i would too take for granted that the issue is no longer an issue and close it.

There are two instances I can think of (I've done it myself) where the bug is important but user does not come back to check on the report after 1 or 2 weeks: 1) Trying out different environment and finding things that do not work. Report a bug with reproducible example and don't check it for a while (months or years) since there is important work to be done in working environment. 2) Find a bug and then find the workaround since work can't wait for external fixes. Report a bug with reproducible example, check the status for a few days with no responses and then ignore the bug since there is important work to be done and workaround has been applied. Now you know one of the reasons why "legacy" code might look messy - it has workarounds for the bugs that may have been fixed...but who has the time to go back and check, change, and test the "fixed" code which may introduce other bugs.

And if not, the bug is probably not important. ¯\_(ツ)_/¯

At some point, you have to close things. Chances are they were spurious, have been fixed or made irrelevant (maybe the code no longer exists) or nobody cares.

And if someone does care and it's still an issue, you can reopen. It's not as if you are permanently deleting all the information for the rest of time.

At my last job, this was the attitude we eventually took with tickets that were several years old.

If it's still an issue with our internal customer [0], they can reopen the ticket or open a new one. But we've completely rearchitectured our systems since the ticket was first opened, our internal customer has changed leadership and has had considerable staff turnover, and not a single person has brought it up in our biweekly meetings with our internal customer for ages, so we might as well just close it out.

[0] when I say "customer", I'm talking about a department, not a single individual

For what it's worth, when I encounter a project doing this I treat it as a giant red flag that the developers don't care about the quality of their project.

In the majority of cases, there's another project that I can move to and I do so as soon as possible.

There are presumably others like me. So when you say it's sustainable, you may not be accounting for the reputational damage it does to your project, which you will almost certainly never be made explicitly aware of because users know it's not worth their time to file bugs.

sometimes it feels to me that people collectively forget that writing software (especially FOSS)'s primary goal is to empower other human beings, before anything else - including our own little developer comfort. Closing unfixed bugs because of no activity really really goes against that in my mind.

Closing issues by itself do not fix bugs.

While reporter is still alive.