Reporting bugs and issues

If you have found a bug or an issue, please let us know! On this page, you can find the preferred way to do this.

1. Make sure that the issue has not yet been fixed already

Unless you are using a very recent development build, the issue might have been fixed already. It is worthwhile to try if the issue also occurs in the latest development version; please see the "Nightly builds" section in Downloading and running test builds for instructions to obtain the latest version.

2. Check if the issue has been reported already

The issue might have been reported already by another user. Please go to https://github.com/musescore/MuseScore/issues first, and search for similar issues before creating a new one.

It might happen that you have done your best and didn't find anything so you created a new issue, but then somebody else says that your issue is still a duplicate. In that case, don't worry!

If you see an issue that basically covers the same problem as you are experiencing, but you can add more information, please write a comment on the existing issue.

3. Report the issue

To report the issue if necessary, go to https://github.com/musescore/MuseScore/issues/new/choose.

3.1. Choosing a template

• Use the Development issue template if you are reporting a bug or annoyance, or to propose simple enhancements.
• The Development task template should hardly ever be used by users; it is usually used by the development team for things that need to be done but are not related to an existing issue.
• If you want to propose a big new feature or bigger changes, please open a Discussion instead.

3.2 Tips for writing the issue

• Don't forget to give the issue a title.
• Please make the effort to fill in the whole template as far as applicable, but feel free to deviate from it when appropriate.
• In case of a bug, please provide clear steps to reproduce it. If we can't reproduce it, we can't fix it.
• If you have the possibility, please add screen shots and videos.
  • On macOS, a screenshot or recording can be made using the built-in tools. Press CommandShift5 to activate it.
  • On Windows, a tool like Greenshot can help; there are plenty of tools on the internet.
• When attaching a video, please make sure that there is an empty line above and below the link to the video. This way, GitHub will render the video inline, instead of that the reader needs to click the link to see the video (which doesn't work well in the Safari browser).
• It may be helpful for developers to include full information about which version of MuseScore you are using; go to Help > About MuseScore… (macOS: MuseScore > About MuseScore…) to open the "About MuseScore" dialog, and click the clipboard icon next to "Revision" to copy all information we might need to your clipboard. Paste it in the description of the issue.
• If the issue occurs in a specific score, please upload the score itself, not only a pdf or image.
  • GitHub does not allow uploading mscz files directly; in order to upload one, you must either pack it in a zip file, or simply rename it and change .mscz to .zip. A mscz file is namely in fact just a special zip file.
• Try to keeps issues as clear and concise as possible. Put any supplementary information in the "additional context" section at the end of the issue template, or consider hiding it with the <details> tag as demonstrated below.

After you report an issue, team members may edit the title and/or description for the sake of clarity and brevity, and comments within issues may be edited or hidden for similar reasons. Please don't be offended if this happens. If you disagree with what we have written then please leave a polite comment in the issue to let us know what you think it ought to say instead (e.g. if you think we misunderstood the problem).

Details (click to show/hide)

Team members spend a significant amount of time reading issues and comments in order to determine what information is actually pertinent to the task at hand, so it is absolutely necessary for us to highlight that information once we have found it, and hide the other information to save others the time of reading it. However, we understand that it can be difficult for contributors to know what is relevant before posting, so that fact that we edited a comment should not necessarily be interpreted as a sign that the original comment was unwelcome.

3.3 Diagnostic files

TO DO