how to best present a fairly long list of suggestions and bug reports?

• Feb 16, 2011 - 19:29

Some of you may have seen the article I wrote up when 1.0 was released:
http://marcsabatella.blogspot.com/2011/02/musescore-10-milestone-in-fre…

I have finished the orchestra->octet reduction project I mentioned in that article (it's the score I posted recently to the Made with MuseScore forum) and am now sitting on a long list of notes I took on things that could have gone better. BTW, I've also started playing with a recent nightly build to find out to what extent any of my issues have already been resolved, and am most pleased to discover that really, quite a lot of what I would have suggested is already being implemented.

It may still take a little while for me to sort through everything and figure out what makes to actually submit as an issue. If anyone - particularly from the development team - has any advice on how I should present my issues, I would appreciate it. If it were just a few issues, I'd just use make my best stab at deciding how to report them, but a quick count shows around 80 separate issues on my list, ranging from very straightforward bug reports, to reasonably specific requests for enhancements to current behavior, to more vague / open-ended ideas for improvements / new features. I'm not sure it makes sense to just open that many new issues in the tracker. Of course, some are doubtless duplicates of known issues, and I'd try to avoid open new issues. Some of my issues have already been resolved for the trunk and do not make sense to raise again, but others might still be worth logging if they are worth fixing for an upcoming 1.1 release.

So again, feel free to offer suggestions ads to how I can make this list most useful.

Comments

• Feb 16, 2011 - 22:18

Just out of my head (I do not belong to the developing core team, even if I have contributed some code), I wold say:

BUGS:

Should be filed in the tracker. Even if already solved (or going to be solved) in trunk, it may be useful for everybody to know there is such a bug AND that it is (being) addressed in the next release.

Of course, I'm speaking of REAL bugs: crashes, lost or corrupted data, ask for a green colour and get it red, ..., not of questionable design decisions or things you expected to go differently.

PUNCTUAL FEATURE REQUESTS

By punctual I mean specific, easy to define and circumscribe: I think they should go in the tracker too; from your posts, you seem to have quite clear ideas and a solid experience in music notation, so your requests are likely to have a solid foundation and to be useful to many.

In particular, suggestions for making the use of MuseScore simpler, easier or to streamline common tasks are quite popular nowadays...

MORE GENERAL FEATURE REQUESTS AND/OR GENERAL DESIGN DECISIONS

For instance:
- entirely new areas or
- features which are likely to require a lot of coding and/or of design or
- changes which are going to deeply affect the programme:
perhaps it is better to post them in the request forum, for them to be discussed (more view points are often useful).

STILL TOO MANY?

If the number of item in each category is really large, you may prioritize them yourself and 'release' them in batch, to reduce tracker / forum clutter.

Alternatively, I assume you may send, via PM, a list to some member of the community you happen to trust in, for a preliminary discussion and, possibly, 'skimming'.
____________________

All this sounds rather obvious once written down, but I do not think there are shortcuts: if something is needed / useful / ..., it is so and it is worth sharing.

Also, as a MuseScore user, I would like to take the chance to thank you for your engagement in improving MuseScore.

M.

Reply

• Feb 18, 2011 - 05:15

Well, the first batch is in. I tried to get the most critical bugs as well as the biggest bang-for-buck feature requests in there. There's still a couple dozen more minor bugs and feature requests that I judge to be either less important or harder to implement; I'll get to those later.

The big picture is this: I identified around 20 bugs that potentially should be fixed in a 1.1 release, even though some of them have already been fixed in the trunk. The worst of the bugs had already been reported, so nothing new there. There are a number of bugs involving text properties and text styles that may or may not be worth fixing in 1.0 given that the trunk implements a rather different mechanism for controlling text styles and properties that is both more full-featured and less buggy.

I also posted a similar number of reasonably specific feature requests, most relatively small. Some may be of the sort that should get more discussion, although some of these have already been discussed quite a bit and I figured it made sense to get them into the tracker.

My overall impression of MuseScore 1.0 throughout this project has been incredibly positive, and from what I see in the trunk, I can see 2.0 will be even better. Hopefully my suggestions will be helpful.

Reply

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