> But just closing stuff that nobody got around to fixing yet is evil.
If nobody is ever going to get around to fixing it, then I'd argue that it needs to be closed.
Which isn't to defend blindly closing issues open more than X days, but in a bugtracker I think it needs to be valid to close an issue was WONTFIX when it might be a valid issue, but the code owners are simply never going to budget the time to get around to it in the next 10 years.
And the bug will still be there and searchable, and people can find it and see the resolution. It may not be satisfying, but the end result communicates clearly that any fix will need to be externally contributed.
Keeping around hundreds of bugs that will never be allocated resources or closed is a drain on the team who is maintaining the bugtracker, they have to periodically go through and curate all those issues, and just looking at the number is fatiguing. The result is usually that people stop interacting with the bugtracker and users really wind up shouting into the void.
There seems to be this attitude by users that they can demand that their issues stay open forever, and that the negative impact on the developers is some kind of punishment for them not having the time to address the issue and that it is unfair to just close issues that won't be addressed, but that's a very self-centered perspective on the part of the user, and the developers wind up suffering a psychological death-by-1000-cuts problem that doesn't help the project or anything get done.
But that means you need to accept at some point that someone is going to kill your baby that you produced and close an issue and tell you that they're not prioritizing it. But they're communicating that they've made a choice, rather than making that choice anyway while leaving the issue open for multiple years and never doing anything about it because they don't have infinite time to fix everything (and every large codebase will always have more bugs than time to fix them).