Hi James, Agree! The whole ticket backlog situation feels very familiar! In a previous project, we did a big clean-up exactly like you're suggesting, *but quickly realized* we needed to address the *incoming* flow of tickets too or we would be right back in "over our heads" in a few months.
Here's what worked for us, and maybe some of it will be helpful here: 1. *Validating Bug Reports:* We found that most bug reports (around 65%) couldn't be reproduced. So, we started requiring clear steps to recreate bugs and gave them 10 calendare days to validate with step by step repo instructions and screen shots. If they were NOT confirmed with documentation, we closed them. They could be reopened with the required documentation making them actionable. No dead / unactionable issues just sitting. 2. *New Ideas:* For new feature ideas, we asked Yes or No: "Does this fit our stated core product vision?" If not, we closed them. For the ones that did, we required customer (in this case community) "votes" from at least 2 members who would support the idea by defining firm requirements using our template. Basically, we wanted to make sure tickets were *really* valid and that new ideas had actual community support. This cut down our ticket flow by about 80% filtering out lowest value / least supported issues. We then focused on processing volume goal. *Example:* 40 issues still in backlog we decided to have them all "done" within 6 months which required working 6-7 per month PLUS plus our monthly flow of 8 issues for total monthly output of 15 issues per month . . . once we accomplish that goal, we held our backlog at at under 20 active issue at any given time . . . if backlog exceeded 29, it triggered an "all hands" call to help get them back to a manageable number. Just wanted to share what worked for us – hope its uesful! Paul
