This is sometimes called a "bug bankrupcty". I'm not that convinced of its usefulness.
Let's apply basic systems theory: if bugs are filed faster than they are resolved, the tendency of the open bug count is toward the infinite. You can declare bankruptcy but it won't change the dynamics of the system: bugs will keep piling up. So you may feel temporary relief, but the underlying problem is still there, causing stress.
You could apply the rule more dynamically: all bugs older than X are always automatically demoted to wontfix status, on the basis that factually, they haven't actually been prioritised for a while. In this case you're using real-world prioritisation decisions to drive the prioritisation status in your bug tracker. This is a more stable solution.
----
But here's where you can take it to the next level. You're de-prioritising a bug for 6 months and then automatically marking it as wontfix. Using "open for 6 months" as the signal to wontfix a bug is relying on a lagging signal.
It would be nice with a leading signal instead, so that you can mark it as wontfix immediately as soon as you know it won't be fixed for six months.
How do you know which bugs fall into the wontfix category immediately? Here's one way:
Make note of the average rate of commits the team is capable of, and decide how much of their time they should spend on bugs, and call the product of that M. Let's say you like the 6 month wontfix threshold, and call this time W. Apply Little's law:
L = M*W
L is the number of open bugs you can have. Find the top L bugs, and mark the rest as wontfix (or the lowest priority level, depending on what angers your users less.)
Concrete example: my previous team committed stuff at a rate of 6.2/day. They spent 30 % of their time fixing bugs. That's roughly 1.9 bug fixed per day. Six months is on average something like 110 workdays. All in all 1.9 * 110 ~= 200 bugs can be open with this the team at any given time.
Anything other than the most important 200 gets marked wontfix immediately.
----
You might complain that it's difficult to say that a bug is less important than 200 other bugs, and you'd be right. Based on my experience, I'd run this with two priority levels and much stricter thresholds. When I have run the analysis on internal bug databases, bugs that are allowed to linger for more than a month are very rarely fixed anyway.
When you have stricter thresholds, you can't just mark everything else "wontfix", because it makes your users angry when it seems like you won't even bother with most of their reported bugs, so you have to add a third priority level that serves as the "probablywontfix" bucket in practise.
- Priority 1 bugs should be fixed within a week,
- Priority 2 bugs should be fixed within a month.
- Priority 3 bugs come without any sort of SLO.
How many open bugs can we have of the priority levels? Same sort of reasoning, but we also need to allocate effort toward priority 1 and priority 2. Let's say 50/50 because I haven't tried evaluating the optimal split.
- Priority 1 bugs open: 1.9 bugs/day * 0.5 * 5 days ~= 5 open bugs
- Priority 2 bugs open: 1.9 bugs/day * 0.5 * 22 days ~= 20 open bugs
- Priority 3 bugs open: everything else.
This you can actually work with.