On reporting bugs

Right now, Miranda's bug tracker gets a big amount of attention by someone who has taken the ball and is currently trying to clear up the mess which has managed to accumulate for the last few months or even years. Based on this, I want to talk a bit on bug reporting - remember that good bug reports are one of the keys to better software quality. A relatively small open source project like Miranda doesn't have its own QA - its quality depends on its users from the community who help with testing and reporting things which need to be improved.

Software has bugs. That is not a nice thing but a fact we all have to understand when using software. Some bugs are critical and have the potential to stop you from using the software or cause loss of vital data, others may only cause some annoyances when using it. Of course, any developer should care about bugs and try to do his best in order to get rid of them as fast as possible. Some bugs will stay though, because they may not be easily fixable or fixing them would require a lot of time and work. Unless, it is a major issue, it should be understandable, that some bugs will rather be filed as a *known issue* for a while before they are adressed when we have the time.

The best place to report bugs is the official bug tracker. Both clist_nicer+ and tabSRMM are listed on the tracker and their bug list is actively maintained. Using the bug tracker has several advantages:

• We (the developers) get notified by email about any change in one of the bug records assigned to us.
• The bug tracker allows to pass a lot of useful information with the report, including screen shots, files and more.
• The bug tracker allows to classify bugs by severity which gives us a good view on the reported issues.

There are, however, some rules you should follow when reporting a bug on the tracker. These rules should help us with identifying the more important issues while setting back the less important things. You may find "your" bug (the one you have found) especially annyoing, but reporting it as major issue when it is, in fact, only a minor annoyance doesn't help much.

1. major, vs. minor vs. ....

A major bug is a bug which may cause a crash or data loss. Anything else it not a major issue and shouldn't be reported as one. An icon being a few pixels off-center is not a major bug, a visual glitch causing overlapping controls in some dialog box is also not a major issue.

Now, you may think that reporting a bug as a major issue will help with getting attention from the developer. But that's wrong. Developers are smart enough to consider the severity of a bug based on the whole report - we don't only look at the classification. Reporting minor issues as major does help no one, in fact, it only creates confusion and it doesn't look very nice when someone views a list full of major issues for the first time.

2. giving all the information

This is even more important. A good bug report should describe the problem and, when it is a reproducible issue, also the steps to make it happen as detailed as possible. Things which can help a lot are:

• crash report with a valid backtrace. The crash report plugin for miranda can often help to identify the location where someone goes terribly wrong.
• All the settings you are using to reproduce the problem. A screen shot of one or more option pages can be helpful and is easier to create than listing all options by text. You can make these screen shot using your language pack - we don't need to be able to read them, since we know the options and their meaning by position.
• Attach files, when needed. For example, if you report a bug with TabSRMM templates, it would be helpful if you would attach a file with the templates you are currently using. If its a problem with a clist_nicer+ skin/theme you have created yourself, just attach it to the report.
• Screenshots. Especially when you report a visual glitch like a drawing error, a screenshot is often worth more than a 1000 words.

Things which aren't much of a help

• Screen shots showing the default error message of Windows (the dialog which tells you that the application had a problem and needs to close). This dialog gives far too less information about the problem and is, in most cases, completely useless for a developer. A full DrWatson report does make sense, though.
• A report that a crash happens without giving information on how to reproduce it.
• A report without a detailed description of the environment. You should list the OS you are using, service pack level and, quite important, any 3rd party software you are running which may have an impact on the functionality. Especially important are details about 3rd party shells (programs which can replace the standard windows explorer + taskbar) or other desktop enhancing tools.

3. Don't forget about your report

A bug report is not a fire and forget case. Often, developers cannot reproduce the issue you reported and can only try to fix it by looking at the code and finding a possible problem. In any case, fixing a non-reproducible issue can be hard and that's where your help is welcome. Don't forget about your report - when a new version of the software comes out, test it and, if the bug you reported seems to be fixed, report it back on the tracker.

We have hundreds of issues which are still open, because the original bug reporters never came back and confirmed them fixed (or still present, if the attempt to fix it wasn't successful).

Well, that's basically all for now. Remember that a good bug report which comes with a lot of detailed descriptions will in most cases make the bug to be fixed faster than a report which is basically useless for the developer. We often don't have the time to investigate things for hours or to make (possibly wrong) guesses on things we simply cannot know because the bug report did not include them.