Closing 45% of the open Emacs bugs
I think it's tough as a maintainer to manage backlogs like this. A lot of people, especially new maintainers, really hate the idea of bugs just lingering unfixed when a lot of them are obviously fixable. Each bug is only a little bit of work, how hard can it be to keep on top of them?<p>I feel like most complex-enough projects are not in a situation where there's the time, resources, or motivation to fix everything. I can't think of any real examples where this isn't the case.<p>If it's a commercial company resources are the concern because achieving perfection doesn't really pay the bills or justify the staffing. In open source, motivation is really the currency and the people who are motivated to fix tens or hundreds of bugs are rare and at high risk of burning out if they attempt to fix everything that comes in.<p>I just think the upshot is that there's usually a significant number of bugs (or usability issues, quirks, whatever) that are not going to be fixed unless something major changes in the project. Directly acknowledging that seems good, whether closing them or otherwise marking them. Keeping it all open seems like the equivalent of keeping a basement full of junk in the off chance you need each bit in the future.<p>I'm not sure what the alternative is. Shutting down the project?