Should we add a field for estimated difficulty of fixing an issue to the issue tracker?
The main use case I see for adding this field is to help with prioritisation of issues and making sure things stay in scope for the next release. For example, issues that are determined to be minor and take large effort to fix could either be marked as "won't fix" or as out of scope for 3.0 but placed on a wishlist for features to consider for 4.0 development.
My suggested categories and examples are:
- Unknown: Default diffuculty. Use it if you don't have much idea how complex it would be to fix the issue.
- High: Issues that most likely won't be fixed or only implemented with a new major version (be it the one under current development or added to a wishlist for the future). Examples would be:
- Translate the entire handbook into Klingon
- Bring back the LilyPond export and make it work nicely this time
- Rewrite the issue tracker
- Medium: Tasks that you'd probably only put into a point release if they're high or critical but otherwise general improvements for the next major release. Examples:
- Write a page in the handbook about a new feature
- Add a new button to the issue tracker
- Create a new category of score templates
I'd specifically like to have some discussion on additional examples for this or if "medium" is too broad of a range.
- Quick Fix:
- Specific spelling and/or grammar issues
- Improvements to Instruments.xml
- Tweaks to a score template
Do these look like good categories and examples to you? This fix, if implemented, I'd classify as medium (see the fact that a field for "version" was recently added: https://musescore.org/en/node/111481#comment-502351)
Comments
Currently we have status and priority. We currently misuse the priority for severity. For example we set all crash as priority critical while some of there are severe but it doesn't mean their priority is high. Some bug trackers often uses severity and priority.
Difficulty/Complexity would then be another one. I don't remember seeing it in other bug tracker and I believe there is a good reason for it. Your examples are easy enough but most of the bugs in the current issue tracker are extremely hard to assess without an investigation that would get one close to solve the bug. Also the number of persons who can make this assessment for MuseScore is very limited (I would say less than 5). I consider myself as one of them, and during GSoC, I tried to gather easy bugs https://musescore.org/en/project/issues/search/musescore?tags=easy, and it's not that easy.
To conclude, I feel like the bug form is already complex enough and I'm not sure another field would help. We can already put bugs as "Won't fix" and if it helps we can add a 4.x version... but what we really need is more people fixing bugs and less new features.
In reply to Currently we have status and by [DELETED] 5
"...what we really need is more people fixing bugs and less new features."
There's often an overlap between those two, though, especially now with the partially-implemented smart layout. For example, #81121: Dynamics and Hairpins overlap could be viewed as a layout bug, or a feature request. Or do you mean that what's most needed is more fixing regressions?
In reply to "...what we really need is by Isaac Weiss
Fixing regressions (if there are any) is always the most important thing. Unfortunately its not the most exciting thing... ;)
In reply to Fixing regressions (if there by shoogle
That is just as true with proprietary corporate software as with FOSS programs. At least there's less pressure to over-promise features in new versions in FOSS land than business land.