This is the first post in my blog series: bugs.kde.org for developers.
In this post I do not want to discuss any specific features of bko but want to give some general advice on how to work with bug reports.
The first important advice I want to give you is to remember that the bug reports are there to help you. They are there to improve the quality of your software, they exist to help you deciding what you want to work on. Remember: the bugs are there to help you!
But you have to help bko to become a database which actually helps you. There are bug reports with low quality, with user support questions, dream worlds, wrong assumptions and all such things. What is important is to improve the quality of the bug reports so that all bugs can help you.
To get to a good database don’t wait for others to do it for you. More than 400 bug reports are opened each week, so don’t expect that there is a team of bug triagers which knows all details of your software to properly triage it. Triagers and users can help in reproducing the bugs but cannot help you in turning the bug into pure gold.
When a new bug is reported remember that it will be in bko for quite some time. We are far away from a bug gets reported and fixed in the next release. The report will be in your search results, in your lists for weeks, months maybe years. You will see and read it more than once.
Every time you look at a bug to figure out what it is about you lose time. You did that once and you should not do it again. Remember: the bug tracker is there for you. The more information you put into the bug report the more it will help you. Is the summary line bad? Change it! It will be shown every time in your search result. Does it not contain any way to reproduce it? Add it! Did the user report multiple issues in one bug? Close it and open separate reports!
Yes it is totally fine to discard everything the user wrote. The bug tracker is there for you and not for the user. There is nothing wrong with opening a new bug report with your technical analysis and setting the user’s report as duplicate. If that helps you it’s fine.
Don’t be afraid of setting bugs to invalid. If the user just did not find an option or used the software in an incorrect way, you can safely close the report as invalid and send the user to the forum. That’s where user support happens and not on bko.
If a user is not able to reproduce a bug and cannot tell you what he did, there is hardly any chance for you to reproduce it either which means you cannot investigate it and cannot fix it. It’s a pity but there is nothing you can do about this bug, so you can set it to NEEDSINFO WAITINGFORINFO. If a user finds this bug and can reproduce it, it can still be reopened but till then it doesn’t help you if it sits there and contains no useful information for you.
Your software is no dream world. Yes bko allows the user to enter “wishes”. But you have to question the wishes. Not every wish should come true, not every feature can and should be added to your software. If we want software which does everything and the kitchen sink there is already Emacs for it 😉 So there is nothing wrong with stating that the specific feature request does not fit with your software and that means setting the wish to WONTFIX. I think that is better and more honest than keeping the wish open for years without telling the user that you will never implement it. And remember bko is there for you and not for the user. If the feature request sits there and won’t be implemented it will be shown in your search results, it limits your possibility to work with bko.
In general bko is very bad to be used for feature requests. So just don’t use it for it. If a user reports a new feature request, just set it to WONTFIX and send them to KDE Brainstorm. That allows the users to discuss it, to figure out whether it is a feature for a user’s specific workflow or whether it’s a real advantage to your software.
Sometimes users report “bugs” which are in fact feature requests. Totally valid and correct behavior may seem like a bug to a user. But if your software behaves correctly, it’s not a bug. So the user is asking for a change in existing and working functionality. Those requests should be handled like any other feature request and not like a bug. Remember the bugs are there for you and not for the user. If it is no bug, it does not become a bug because the user yells. And if you think the feature works correctly the way it works, then again it’s a WONTFIX even if the user thinks it’s a bug. And don’t discuss. Users try to discuss such decisions and such discussions should happen – if at all – on brainstorm. Make it clear that discussions won’t help anything, that it takes away your time to fix bugs and if that does not help just ignore the bug or get help from the community working group. Users have no right to question your decisions about which features to implement and which not. If they want it implemented they can implement it themselves, hire someone to do so or whatever. But even then they don’t have the right to get the code in, though they can fork and whatever. Our license does not require that we build a kitchen sink.
And my last advice for today is: don’t expect to change bko for your product in a day. It’s a process which will take months and maybe you will benefit in a year from it. But it’s worth it, so invest the time.