Sign in to follow this  
Kevin Collmer

How to report a bug

1 post in this topic

Isolate bug
The first step in in writing a bug report is to identify exactly what the problem is. Saying "something is wrong" is not helpful; saying exactly what is wrong, and how to reproduce it, is. If you can tell exactly what is wrong, and reliably reproduce an example of the problem, you've isolated a bug.

Check if you are using the latest version
Bug reports should be based on the the latest development build . If you are using an out-of-date build, please update to the latest revision and check to see whether or not the bug still exists.

Check if the bug is known
Please check whether the bug you are experiencing is already documented. If it is already documented, you may click "subscribe" to follow any developments. If your bug is different than any others recorded, open a new bug report.

File each issue separately
If you have multiple issues, it is better to file them separately so they can be tracked more easily.

Create a new issue
There are a number of initial questions that are used for filing a bug report - answers to these allow progress.

The first question is which project your bug applies to. If in doubt, leave it empty.

The version in which you discovered the bug (e.g., 4.0.0, or ATLAS). If you can reproduce the problem in more than one version, select the earliest.

Finding the component is sometimes difficult. When in doubt, use "Code" or "UI".

A "bug report" is usually for when something contrary is happening to what is expected: An example of a bug could be: open a specific file, but it instead crashes.

Every bug will have a different priority.

"Critical" is used if any of the following happens:

Data/Fund loss
Inability to save work
Certain irreversible operations
Hangs and crashes


Common feature incorrectly/not functioning
Otherwise critical issues, if they happen only in some very rare and esoteric corner cases.

All other bugs are considered "normal" or "minor" priority. Bear in mind that while a bug that you are experiencing is important to you, developers have to balance it with all the other known bugs.

The title should describe the problem as best as possible. Remember that the title is read more often than any other part of the bug report.

Poor title: Notes don't display correctly
This title is not specific enough for someone to look at it a month from now, and remember what the bug report is referring to.

Good title: Stems too short for 32nd and 64th notes
This title is an improvement over the previous title, because it specifies the type of notes that are affected and identifies the display problem.

After submitting the report, it is possible to improve the title.

Steps to reproduce bug
A bug report requires clear instructions, so that others can consistently reproduce it. Many bugs require some experimentation to find the exact steps that cause the problem you are trying to report. If you aren't able to discover these, try obtaining some help on the forums instead.

Expected behavior
Describe what should happen if the bug was fixed.

Actual behavior
In contrast to the expected behavior, describe what currently happens when the bug is present.

Version number
Find out the version you are using. For example: "Version: 4.0.1 ATLAS".

Operating system
Name the operating system and version you are using, such as "Windows XP SP3", or "Mac OS X 10.7.5".

File attachments
If you can supplement your bug report with an image or crash log that helps others reproduce the issue, attach these files.

Following up
Once a developer marks a bug as fixed, it is a good idea to ensure that it is completely fixed. To test, download the latest build.


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this