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