Free software projects heavily rely on user feedbacks, especially bug reports. Filing bug reports is one of the best ways for a user to contribute to his favorite app and make it better. However at times lack of proper bug report makes it harder for a developer to understand what problems a user is facing. So as important as it is to file a bug report, it's more important to file it correctly. Incorrect bug report irritates a user as he feels that no one pays attention to his report and discourages him to file a report in future. At the same time it irritates a developer because he wants to know what's wrong, help the user and make the application better he doesn't even understand what the problem is.
Bug vs support or feature request
Before filing a bug report it's very important to know that it's about a bug and not a support or feature request. Amarok crashes when you try to scan your library can be bug, but if you want to know how to add a new library to Amarok, it's not bug it's a support request. Similarly, if you want image art to appear with track names, it's not bug it's a feature request.
Do your homework.
1. Everything that's old is not gold
It's a tricky thing, but very true. If there are problems with the app you are using make sure you are using the latest version. Quite a lot of bugs are fixed with every new release. Sometime there are bug fix releases only. So, ensure that you are running the latest version of that application. Now, why is that tricky? Because depending on the distribution you are using you may or may not get the latest version from the standard repos. Also check the release-notes/change log of the latest release and see if that bug has been fixed in that release (though it's not guaranteed that all bugs will be mentioned there). So, depending on your distro try to install the latest version and see if the problem persists before filing the report.
2. Is there already a workaround?
Before your file a bug report, Google if others are also affected by that problem. In the free software world, the development happens at a faster rate and things keep changing. Chances are it's not a bug but an after an update the app or package behave differently, so check online and you might fine a solution. If there is already a solution, you don't need to file the bug report.
3. Does the bug already exist?
Before filing your bug, search the bugzilla if the bug has already been reported. If the bug is there you can see the progress or interaction with the developer. If the developer needs more information about the bug you can give the feedback. You can speed-up the process of bug fixing by giving your inputs or simply telling that you are also affected.
4. Ready to file?
If there is no solution and no report already filed, you are ready to file the bug report. But as they say, unless you ask the right question, you won't get the right answer. You need to file the bug report correctly so that it can be easily understood by the developer. If you have stomach ache and you go to the doctor. Simply telling that it hurt in your body won't do any good. You will have to tell where it hurts, how much it hurt, what you ate, etc. Same is the case with bug reporting. You need to be clear and precise. 'The app sucks' is not a constructive bug report.
One single factor that can make your bug report useless is whether it is reproducible. Can your bug be reproduced? If not, don't file it. Why it matters? Because the developer should be able to reproduce the bug and see what's happening. If he can't reproduce it, he can't fix it. So, second most important thing is write in very clear and simple language how to reproduce the problem. Give step-by-step instruction to reproduce it.
Lost in translation
Free Software community is a global community where developers from around the globe are contributing. Fortunately there is one common language that most of us understand well. You may be living in India but the software that you love may be created or maintained by a German developer. You don't understand Duetch and he doesn't understand Hindi, but both may understand English, so file bug reports only in English.
Filing The Bug
If you have gone through all the above mentioned steps, and have reached to no solution, no you can head over to file the bug report. Since this article is about KDE, the basic idea can be applied to other technologies as well.
You can file KDE bugs here.
I reached out to some KDE developers to see what have to say about a good bug reporting.
Thomas Pfeiffer-
A few things come to my mind as quality coordinator for Plasma Active:
- Try to reproduce the bug yourself before reporting it. If you can't reproduce the bug , developers most likely won't be able to reproduce it either (unless you were able to retreive a very good backtrace) and the chances that it will be fixed are close to zero
- Provide detailed steps to reproduce the bug. If you were able to reproduce it, this should be possible in most cases. Some bugs seem so random that even though they happen more than once, it's difficult to tell exactly how to reproduce them. But even in these cases, any information is better then no information
- Select the distribution you use and the software version (KDE SC or application version if it has its own versioning). Many bugs turn out to be distro-specific after a developer tried in vain to reproduce it on his/her machine with a different distro, and a bug report which does not provide the affected software version is pretty much useless.
- If it's a crash, provide a backtrace (with debug symbols installed). Unless it's very easy for the developer to reproduce, chances to fix it are slim without a backtrace. The KDE Crash Handler (DrKonqi) is very helpful here, so use it! Let it install debug symbols for you if your distro supports this.
- If it's something that can be seen clearly on a screenshot, attach one. A picture often says more than a thousand words in a bug report as well
- If you don't see any action on the report at first, don't start whining in the comments. This won't help you - or anyone - at all. If you think a bug is serious and affects many users, try to get others to confirm it with under different conditions and provide additional information that may be helpful to the developers in the comments
Martin Gräßlin–
I'll add a few more point to the list:
- reproduce with latest version. If you have 4.9.1 and the current version is 4.9.5, the first comment the user will get "please try with latest version". In many cases some common bugs are fixed in deed. Also reproduce with the latest SC (major) version. That is currently I'm not interested in bugs for 4.8 any more, because it's a year old.
- Come back to the bug and report update states. But don't annoy the developers. If there is no info from the devs a "not fixed in 4.9.1", followed one month later with 4.9.2 and so on, just annoys the devs. But if there is a new major version it's great to add the info like "just tested 4.10 RC 2 and problem is still present".
- Respond to questions asked by developers. If you don't understand the requests, it's fine to ask for help - the devs will give it. If you cannot provide it, just state so, then the devs know what to do about it. Always reply. For the devs it's easier to have a reply when going through the bugs than to see that questions have not been answered for months.
- Don't assume things. A user cannot know the component of the bug. Don't tell the devs where the bug is in the code, it's the developers task to investigate the bug. A user cannot know where the bug is and it might be somewhere else than the user would think. It makes the report difficult to read
- Don't argue with the developers. If the developer decide to not fix it, further discussions won't help. That's especially important for feature requests.
- Don't tell the devs how important that bug fix would be for you. Developers know that it's important to you, otherwise you would not have reported the bug. And that's the case for all bug reports. So developers have to decide which bugs to spend time on based on what is most important for the user base and that might not include your bug if it is a rare one in a hardly used component.
- Don't rally for people to "vote" for it or add a me-too. Devs notice that and it's not helpful to get it fixed. Devs also read the comments on the dot, read Google+ and read identi.ca/twitter. If you rally for the bug to be fixed, they see it and will ignore it.
- Don't demand action based on how many people have voted. That feature is just broken. Currently the bug with highest votes is 1499. Given that people can give 20 votes per bug, it's nothing compared to the userbase of KDE.
Why no one responds to your bug report?
If you have done everything by the book and still no one is responding to your report there can be many reasons. One of the most common reason is that the developer is no more looking after that project or he has so much work that even if he wants, he can't handle your request at the moment. If you see no activity for a while (not within 2-3 hours, but for a week or so) you can always try to politely send a reminder. Just keep in mind that the developer is not getting any money to maintain or write that program they are doing it for their passion for the free software and to make their work available for the rest of us.
Happy hacking!
Tags:
KDE
View the discussion thread.