Reporting bugs

Software has bugs. That is not a nice thing but a fact we all have to understand when using computers. Some bugs are critical and have the potential to stop you from using the software, 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 addressed when we have the time.

Where should I report bugs?

For TabSRMM and Clist Nicer, the best place to report bugs is the official bug tracker. Both plugins 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 screenshots, files and more.
• The bug tracker allows to classify bugs by severity which gives us a good view on the reported issues.
  
  

The other plugins, hosted on this site are not listed on Miranda's official tracker, and you should not use it for reporting bugs. Instead, use the issue tracker at my googlecode site.

Please do NOT use the Wiki pages for reporting bugs. That also applies to Talk pages. If you are absolutely against using the bug tracking systems, you can also use my forum.

A few rules, how a bug report should look like

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 annoying, but reporting it as major issue when it is, in fact, only a minor annoyance doesn't help much.

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.

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 screenshot of one or more option pages can be helpful and is easier to create than listing all options by text. You can make these screenshot 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.
• Screen shots. Especially when you report a visual glitch like a drawing error, a screenshot is often worth more than a 1000 words.

The more information you can provide, the greater are chances that the bug will be found and fixed quickly.

Things which aren't much of a help

• Screenshots 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.

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 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.

Author: admin Last modified: Saturday, October 23, 2010 at 20:24 CET

Category: Main?