Updating Priority management in the issue tracker
Hello everyone!
Almost a year ago we have updated Severity and Priority categories in the Issue tracker to make them reflect actual priority and importance of the relevant issues for the further development of MuseScore. Although this has improved the process of prioritizing and resolving issues, current state of the issue tracker does not seem to be always correct about issues priorities. We have a large number of issues which have P0 - Critical priority declared which remain unfixed for over a year. On the other side, we have a large number of really important bugs tagged as P1 - High, although some of them seem to be more important than some of those tagged with P0 priority. Therefore we would like to propose revising Issue tracker priorities once more and defining a general set of rules which should help in deciding which priority should be assigned to a particular issue. The proposed rules are as follows.
Priority assignment rules
- No priority
- Unconfirmed bugs;
- Suggestions which profit for MuseScore is not clear at the moment.
- P0 - Critical
- Issues with S0 - Blocker severity;
- Significant regressions;
- Tasks which have a large priority according to the release plan.
- P1 - High
- S1 - Critical severity tasks which can be reliably reproduced or which are frequently reported by users;
- Tasks which are desirable (but not critical) to implement according to the release plan;
- Most frequent users' suggestions (S5 - Suggestion) if their implementation is considered useful for MuseScore;
- Most frequently reported and discussed bugs with lower severity.
- P2 - Medium
- Confirmed bugs and relevant suggestions which did not fit to P0, P1, and P3 priority categories.
- P3 - Low
- Confirmed bugs and relevant suggestions which have relatively low impact (S4 - Minor, some S3 - Major issues) on the user experience with MuseScore.
Conclusion
Feel free to post any suggestion regarding the issues prioritizing rules and process in the comments. We are going to revise the existing issues in short time based on these (or corrected) rules. Hope this helps to prioritize them more clearly!
See also
- Update on the Priority/Severity categories in the issue tracker (March 1, 2019)
Comments
The only obvious policy shift is to no longer automatically treat all suggestions as high priority; which in my view is a good thing to do.
A review of P0 and P1 issue can't hurt. After all if a P0 was indeed critical, meaning it renders the product useless, there shouldn't have been releases (apparently for over a year) until those are dealt with or mitigated into a lower level (perhaps due to workarounds or disabling the offending part).
Looks good.
In reply to The only obvious policy… by jeetee
My take on what happened during the beta and run up to the initial 3.0 release was a sort of unofficial party line of "all P0 bugs will be fixed before 3.0 release" that eventually morphed into "only P0 bugs will be fixed before 3.0 release. So in practice, people (myself included) tended to use P0 to basically mean, we feel this should be fixed before release, even though it might have seemed quite so high a priority by other measures.
In reply to My take on what happened… by Marc Sabatella
My hope here is that with this proposal P0 category will indeed contain only the most important issues so that we could actually fix them before the next (minor or, if possible, patch) release. If so then it should no more lead to situation where number of P0 bugs was too large to consider working on issues with lower priorities.
I would say the system that was devised last year was good for the conversation it started, the changes it led to in the issue tracker itself, etc. But the actual definitions of the priority and severity levels was confusing and ultimately not that helpful. I think this proposal comes a lot closer. It seems more common sense, easier to follow, and I'm more optimistic it could be applied and somewhat consistently.