3.0 development and the Issue tracker
We've released 2.2 and it is time to move further.
Development of 3.0 is a priority for us. A huge amount of work has already been done there. 3.0 is usable enough for the simplest cases. Werner defined the major issues which are known. The list of the fundamental changes and the related tasks will be published as EPICs in the tracker, soon. Many small issues have already been created in the tracker.
The main idea is to organize tracker so that contributors may find the most important issues for the current goal. The goal for 3.0 now is to make it public (as an alpha or early access version) as soon as possible to get feedback from users. We have issues that block users from their user-scenarios without possible workarounds. So, the first and the most important step is to put all the known issues to the tracker and define the priority for them.
The first priority is the issues which are blockers so that users are not able to use 3.0 for creating scores at all. These issues should have Major priority and 3.0-dev version specified. MuseScore core team will use tags to organize issues. So, the most valuable issues will be under 3.0alpha and 3.0alpha-XX tag. 3.0alpha tag means that the issue must be fixed before the official 3.0 public release so that 3.0alpha issues are release-blockers. 3.0alpha-XX tag (where XX is a month code, e.g. 3.0alpha-07) will be used for the issues which must be fixed until the end of the specified month to release another 3.0 alpha package to the public. The tags are specified by the core team and show the actual priority for the development.
As an example see 3.0alpha tag search and 3.0alpha-06 tag search. We've just started compiling the issues backlog using this idea, so the number of issues under the tags is small.
As an example of EPICs and the related tag, you can see musescore.org related issues and the related tag search as well as MusicXML import/export issues and the related search.
It is important, there are no limitations for the contributors and the whole community. It is just a priority for the product, so if someone wants to help with bug fixing, it is welcome, so he/she may follow the actual 3.0alpha-XX tag. If someone wants to implement the particular feature or fix the particular bug which is not under the tag, no problems, you are welcome as well!
New feature requests are better to create with 3.x version, since 3.0 has a lot of know issues, so the priority is to implement the known stuff and make the public stable release.