When you get more bug reports inbound than you can fix, you have bugs that will never be fixed. A good method of keeping your list of bugs to a manageable size

When you get more bug reports inbound than you can fix, you have bugs that will never be fixed. A good method of keeping your list of bugs to a manageable size is to simply declare that if a bug cannot be fixed in $timeframe, it should be closed as WONTFIX. Acknowledging that the bug or issue will remain because the projects resources have more important things do do, and it will never be dealt with unless some external factor is added (eg. a volunteer with skills prepared to prioritize the work). It also acknowledges that the longer bugs sit open, the less relevant they become. The feature they apply too may have changed beyond recognition, becomes deprecated, or the bug metastasizes and becomes a feature. It acknowledges that long open bugs are going to be reported multiple times anyway, and at least this way you get fresh, current reports rather than everyone dog piling on an ancient ticket that nobody wants to get near. You know the ones, where it has mutated over time that the initial report from 2008 bears no resemblance to what is currently being discussed, but everyone is cranky because it has been open 12 years and obviously the devs all suck... doesn't really inspire you to deal with it. So you triage your bugs into roughly the same size chunks. You measure how many of the issues you deal with per month. You prioritize the issues. If you have more issues than your monthly velocity, you close the lowest priority WONTFIX because, well, they will not be fixed. But nobody does it this way for public projects, because then they have to deal with entitled people who want their priorities to supersede your priorities, and instead you end up with an eternally growing list of bug reports that are harder and harder to maintain. And try other approaches to make it maintainable, such as making it harder to report bugs.