I try to periodically triage new bugs, making sure that they all have tags. At some point, I had every bug tagged, but then some of them didn’t fit into any tags, and five became thirty, and then I got demoralized. I still try to do it every so often.
I never tried to assign levels to things, but if that’s something we want to do, I can try to do it.
As we discussed on IRC, I have sometimes considered four categories:
Fix it now.
Retriage regularly (say, every release).
Retriage periodically (as a background task).
Do not retriage unless requested to do so. Will get fixed when it gets fixed.
Currently, we don’t have the “retriage regularly category”, I don’t think. I would sort of like to use a milestone-per-release as the “fix it now” category; P-high for retriage regularly; P-medium for retriage periodically; and P-low for “do not retriage unless requested”.
The idea would be that after every release we focus on p-high bugs, than focus on p-medium bugs until the next release.
At some point we also discussed the idea of reviewing issues opened since the last triage meeting and so forth. But I think that would require more regular meetings.
I agree with this direction, but want to point out that P-high are retriaged every three weeks, and we are cycling through P-medium as well, so they are retriaged regularly.
I will post a thread to irlo suggesting we create release milestones, and define them as ‘must fix right now’; and defining P-high as high-priority per team opinion; both retriaged every 2 weeks in this meeting.
Once complication with this use of release milestones is that the roadmap RFC may end up also using release milestones for estimated goal completion. This means it would have two purposes - critical bugs, and tracking non-critical but expected features. I’m not sure this distinction will matter much as long as we’re continually retriaging them.