Even when looking only at recent ticket activity, overall popularity of a project also plays into it. A young project that generates a lot of interest may attract a lot of reports and still work great. An old, unpopular project may be a hot mess but the ticket count is low because the user base isn't there to find issues in the first place.
Re:GitHub Stale Bots – A False Economy
by onionisafruit on Monday January 18, 2021 @11:15AM
(#25823183)
Number of issues shouldn’t be a primary factor in evaluating a project. Maybe GitHub should stop featuring that so prominently in the UI.
- not having "TOTAL issues" as a counter, but "TOTAL RECENTLY ACTIVE issues", for some value of "recently" - defaulting to only showing the RECENTLY ACTIVE issues when searching for them (or finding them through other views) - displaying a warning such as "this issues is dusty, consider it not being prioritized highly"
As with all other bug reporting systems, having slices/views to work with seems to be preferred to closing issues. Someone supporting the product might really want to find the issues being "most reacted to" recently, the planning "product manager role" maybe only wants to see the high level "epics/initiatives/visions" in a certain order, etc.
I think much of this comes down to all issues being on the same "level" in a Github issue tracker, i.e. "tagging is enough", which some projects solves with a huge taxonomy, and some don't.