Issue triage roadmap
From @markglenfletcher:
Our main target should be to regain control of the existing issue backlog and incoming issues within the GitLab-CE issue tracker, using it as a test bed for applying whatever techniques we employ across other GitLab-org issue trackers.
I think it would be good to define some high level (measurable) targets for where we would like the issue tracker to be within the next couple of months, so that we can work out some method of achieving them. We can measure before and after to see where we are:
Target | Measure | Priority | Notes | |
---|---|---|---|---|
1 | No existing unlabelled issues | Yes/No | Very High | This is really important, there could be important issues that haven't even been read. Unlabelled issues are very likely to be lost |
2 | Decrease the number of total issues by 20% | Overall decrease between points | High | This is important the more issues there are the more difficult it is for the team and contributors to locate issues |
3 | Decrease the number of issues with ~bug label by 50% | Overall decrease between points | High | Important to improve product quality, important to have an accurate bug count |
4 | Decrease the number of issues with ~"feature proposal" label by 20% | Overall decrease between points | Medium | We will always have feature proposals, but it would be good to cull the duplicates and issues we are sure we won't do |
5 | Incoming issues triaged within 72 hours (allowing for weekend) | Unsure of how to measure this (there is no event type for applying labels) | High | Issues left to languish are less likely to be fix and more likely to be lost |
6 | Decrease the number of issues with the support request opened on the tracker | Overall decrease between points | Medium | These issues affect metrics and divert our time from the addressing the above points |
Edited by Rémy Coutable