…..And I will try to fix you
Who doesn’t love themselves a bit of bug triage? Answers on a postcard, please.
“Triage is medical term referring to the process of prioritising patients based on the severity of their condition so as to maximise benefit (help as many as possible) when resources are limited.
Bug triage is a process where tracker issues are screened and prioritised. Triage should help ensure we appropriately manage all reported issues – bugs as well as improvements and feature requests.”
Bug trackers can be a massive headache. How we handle bugs, if at all, can be a matter for debate. Here is my triage tale.
A mountain of bugs is horrific, it doesn’t paint a great picture for the health of your project. Especially if they’re live (read: open).
There are three considerations that we have narrowed down to:
- Bin the lot, throw them away and start again, ensure this horrible mess never rears its ugly head in this state again.
- Close all bugs older than XX months, ensure this horrible mess never rears its ugly head in this state again.
- Triage the lot, retain those that are still applicable, ensure this horrible mess never rears its ugly head in this state again.
I’ve already stated before my love of data. So, knowing that, I need to be mindful.
“I am drawn to collect and retain all the data that is humanly possible, almost as a gut reaction. But, on reflection, is all the data really what I need? What my company needs?”
However, I am really not keen on options 1. or 2. – there could potentially be some very valuable information, or issues not dealt with yet and arbitrarily closing them off has potential to be careless.
We are moving from one bug tracker to a different all encompassing super-tool (exciting times). So now is the time for change, and I am going to seize it. What has happened before isn’t sustainable.
I’m going for the long route, and here’s the plan, two pronged:
- Perform triage on the existing issues, only porting those that remain valid to the new tool.
- Collect and collate the bug tracker users’ requirements and feedback from the old bug tracker (and its processes). Using that along with informed expertise from myself and interested parties, to correct the process and implement a more robust bug handling and lifecycle process.
The email for feedback is out now, the replies are coming in, this is happening. Triage on legacy issues is also taking place, it is arduous and can be time consuming, but I’m grateful for those helping and for the opportunity to try to tackle it.
I will follow up, wish me luck!