Posted on by Martin Flöser

BKO: All the bugs belong to you

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.

13 Replies to “BKO: All the bugs belong to you”

  1. So if i have submitted a wish to bugs.kde.org and you said to post the wish on kde brainstorm, what’s next?
    How can i be sure that people behind the affected project read this brainstorm?
    Or i should follow users’ opinions on brainstorm and at some point should make the request on bko again?
    How do i determine the right time for this?
    If not, then why there is `wish` category on bugs?

    1. the idea behind brainstorm is to have users evaluating the feature suggestion. Only if the suggestion gets enough support it is forwarded to the developers. This adds a useful filter between the users and the developers.

      1. Who decides and using which criteria ” if the suggestion gets enough support”? Who forwards the idea to developers?

        1. I think we need another series for users, which would describe the principles and the workflow behind KDE development, how to effectively to contribute to KDE…

        2. I do not know about the criteria but several brainstorm ideas have already been forwarded to the developers.

  2. Awesome post, Martin. I virtually completely agree. When triaging I come across many old bugs/soft feature requests that obviously are never going to be fixed – but it is up to the dev to set it to wontfix. A few weeks later I come across the same bug again – thus waisting time again. In general, KDE seems much to hesitant in closing reports. To me, reopened reports form no problem, but 50% air in the open bugslist is, because that makes it impossible to find duplicates, get priorities etc out of bko.

    I also agree that bko functions poorly for feature requests. But what do you do with stuff that technically functions well, but not in terms of usability? An example that comes to mind is the suspend inhibition icw closing a laptop. Is that a bug or a feature?

    1. I also agree that bko functions poorly for feature requests. But what do you do with stuff that technically functions well, but not in terms of usability? An example that comes to mind is the suspend inhibition icw closing a laptop. Is that a bug or a feature?

      I would say neither nor. Usability issues should be handled by a dedicated and well informed usability group and then come with concrete proposals to the developers. Saying the usability is bad doesn’t help at all if the developers are unable to do it better.

  3. Nice post! I do change bug summary regurarly, glad to see you mention it.

    However there is one complaint from me about those “triaging sessions”. I’m not sure if “power users” should be doing the “triaging”. I’ve had one case where a bug was about to be lost because of a “triaging session”, and probably am not alone. It’s the devs, IMO, that should sort the bugs, not the users, be they power users or not.

    1. In a perfect world, yes. But devs tend to have better things to do. But the Plasma bug triaging round of last fall brought the number of open bugs back from 1600 to 900 – and now it is up to 1100 again. Once in a while, you just need the massive clean ups. Sure, some bugs will be closed by accident. But it is also the responsibility of the reporter to check whether his bug was actually solved. If it isn’t, shout, and your bug will be reopened.

      And especially for kwin, plasma, pim, and such: All bugs are shallow. Even if a bug gets closed by accident (which in principle should not happen), another reporter will post it very soon. After all, it is not like KDE is running out of bugs to fix.

      Having said that, you are doing great and dedicated work right now with the Folder Widget bug fixing.

    2. yes I (nowadays) also think that developers have to do the sorting. Triagers are great to filter out the bad reports on the other hand. All the reports which cannot be reproduced, user support issues and so on. Filtering to a dedicated component has to be done by the developer – and that will be one of the next posts.

  4. Thanks for this post – BKO has a long way to go, and I hope this helps it getting there 🙂

    One note on the bugreports that are feature requests: Actually, some (many? I do not know) of them are actual bugreports, just against the wrong component. The bug is not that the program did what it did, but that the user expected it to behave differently. This may not be solely because the user lives in some dream world, it can also uncover some serious user interface issues, miswordings in descriptions, unintuitive arrangement of GUI elements, and so on. After all, there usually is a reason for the user to expect some behaviour, and probably others will have had the same “bug” (it’s a bug for them so they will consider your software buggy) without reporting it. IMHO such bugreports have to be taken as seriously as those uncovering actual bugs in an application, especially if they occur repeatedly.

    I’ve been both user and developer when dealing with such bugreports 😉

    1. It’s the task of the developer to identify useability issues mentioned in the reports and to create a new report for it which is just about the specific useability issue and not a bug about “a missing feature” which turned out to not have been found by the developer.

Comments are closed.