Issue tracker "Priority" suggestion

• Dec 12, 2014 - 18:14

This has come up before, but I am prompted now by #41291: Switching concert pitch when using transposing instruments augments the keysignature on each line. to bring it up again.

We've kind of settled on a convention where "critical" priority is reserved for - and pretty much always used for - crashes and corruption. I've said before that ideally, we should have separate feilds for the "severity" versus the "frequency" - a crash that can only happen on odd-numbered Tuesdays when performing a certain bizarre sequence of operations involving a combination of figured bass and feathered beams is much less critical than a crash on open of any score containing a half note. But I gather that would be a pretty significant change to the structure of the issue tracker.

What about just adding one new value for priority, "serious", that could be used for things that aren't crashes or corruptions but that someone feels should be elevated in priority in some way anyhow? We could also perhaps downgrade soem existing "ciritical" bugs to "serious" if they are of the Tuesday-figured-bass-with-feathered-beams variety.

Sure, some users will submit things as "serious" that really aren't especially, but that's already the case now with "critical" (and occasionally "normal" versus "minor"). We can just continue to override
this as necessary.

As it is, I have been maintainging a list at http://musescore.org/en/issue-hit-list-marc-sabatella where I have been using bold face to indicate bugs I think are especially serious. lasconic has been using "tags" (a feature not available to everyone) for a similar purpose. I don't plan to keep up that list post 2.0, but it might be nice to have some way to actually mark bugs in the issue tracker in a similar way.

I guess another possibility is a new value for "status" - something to connote "investigated and acknowledged as especially important".


Comments

Thomas just added a "Major" priority.

The "Critical" category is indeed reserved for crashes or loss of data. Since MuseScore is not really a critical piece of software so we could demote the critical bugs with very low frequency to "Major".
Let's use "Major" for bugs and regressions that have a significant impact on the software performance or on the user experience.

Do you still have an unanswered question? Please log in first to post your question.