Score with countless Smart Layout problems in 3.0-alpha

For the record, I am a big fan of MuseScore and have been for a few years, since I discovered version 2.0.3. I contribute the only way I know how to make it the best music notation software in the world. In many peoples' opinions it's better than Finale and Sibelius. It is neither of these programs, so you will never get everyone to think it's better and I've never used either.

First of all, as you should know very well, I have been testing the alpha release and giving feedback. I open issues when I'm reasonably sure they are not already reported and make comments in the forum when I'm not sure. This is usually because I remember seeing an issue report on the subject but don't remember which word to use to find it. Face it, the search feature on this site is sorry. Discussion on these comments would be most welcomed. There are no doubt in my mind some major issues I don't know how to reproduce on demand. I don't want my issues to be put into "Needs more info" status and forgotten, which is the usual result.

I did very little programming in C 30 years ago, so I remember some things, but I'm in no condition to learn C++ to help in development, so I contribute the best way I can.

Automated testing can only go so far as you have stated. The ultimate test is to have a human try to break it and make sense of it. Music being its own language, as you said, greatly limits any automated testing you can do. Getting testers to actually post results on the site is an entirely different problem. I monitor several of the languages besides where I have seen you, and there is very little feedback on the non-English forums from testing. Actually, besides the issues that are mostly created by the usual users, few people actually create bug reports. I don't believe these testers are not finding bugs, I believe that for some reason they are simply not reporting them either in their own forum or the issue tracker.

As far as critical and major categories are concerned, perhaps there needs to be some rethinking or clarification. Here's how I loosely classify them. If it crashes, it's critical and there's no gray area. If there is a problem that causes the score to be unusable it is at least major and becomes critical if you can't open the score. If an average user can easily workaround the problem then it is major, otherwise it is critical. If it has to do with how items are displayed, it is typically normal, but I can see it becoming major if, for a hypothetical example, the notes are displayed on the wrong line or some similar situation. If the problem requires a huge zoom to see, then I consider it minor, otherwise its normal. If something just doesn't work the way its supposed to, I make a decision of minor, normal or critical based upon how easily you can accomplish the same thing. If I don't know what else to call it, its normal.

There are things you, as the program manager, need to do to assure these are accurately tracked. First, don't leave a status with the word patch in it. You either need to accept or reject the patch and explain the problem if its rejected, either in the issue tracker or git-hub if more appropriate, but you need to change the status to an appropriate state (like active, needs info, won't fix or by design). There are some (only looking at 3.0/master) that have been in this state for 2 years, some are major and critical. Does anyone know if these need to be fixed still?

You need to look at the 2.x issues and decide if they are applicable to 3.0. If not, they need to be closed, otherwise they need to be fixed by someone. 2.1 and before bugs, should not exist in 3.0. 2.2 and later bugs, should probably be fixed in version 3, but they are a bit more understandable to still be left open. I have noticed that you have been working on this.

You have a paid staff that works on some of the programming for 3.0. It seems for the most parts they do not make issues, they simply program, and that's fine. They obviously work on what you want them to work on. If there is an issue you would like a volunteer to look at, perhaps you could make a request for someone to look at it, and no doubt someone will respond that they are on it. You have volunteers who put in a lot of work and do some major projects, like Figured Bass, a lot of the tablature, many of the accessibility features and currently revamping the jump system and creating a Shamisen tablature among others.

If you are using the same metrics you used to release versions 2.2 and 2.3 then you need to rethink your metrics. There's something you're not taking into consideration. I was honestly shocked when these were pushed out. I won't do more than say that your last IOS release appears to have been a total disaster, and people pay for that. Ultimate Guitar is also responsible for both the .com and .org sites. Support for these has been far inferior to when a single person was responsible for most of the support for both sites. The same bugs, from a users point of view, seem to come and go constantly, especially on the .com site.

If there is something I can do to help further improve MuseScore, do not hesitate to ask. I'll let you know if I'm capable fulfilling your request.

exactly what I meant to say

I completely agree. Many developers regularly push out updates to their apps. These updates do not necessarily bring new features, but do resolve issues that occur in the previous version. Whenever my apps update, I am encouraged that the developers care enough to deliver bug fixes to their users. This is the model that I would like to see MuseScore adopt, and it looks like we are indeed moving in that direction.

It is not true. Please, look through the history on the forum before the acquisition and you will see that 2.2 was scheduled as the last step in 2.x releases. Btw, UG initiated development to push forward notation and playback for percussions, that's why we released 2.3.

Let's concentrate on making 3.0 alive and great. Discussing the past in such a way doesn't help much :)