No other approach is sustainable.
It was five years later that someone came along and closed the bug.
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.
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.
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.
Obviously. (Isn't it? Not sure why this explanation is appearing as a reply here. How could the previous comment have been written without a strong understanding that there's distinction? Why would it have been written unless there was a strong belief in the distinction?)
> we still track it until the customer is unblocked
As you should... in some place that isn't the bug tracker. (See "muddled.")
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.
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
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.