Making it easier to submit bug reports

New Contributor Friendliness 1 Minute

A persistent complaint KDE faces is that it’s too hard to submit bug reports. One obstacle was the giant scary list of products at https://bugs.kde.org/enter_bug.cgi. Well, no longer! This page is now organized into logical categories with user-friendly text, so it should be much easier to find the right place for your bug report if that’s your entry point. This has been rolled out already and is available immediately:

There are also other entry points; for example all KDE apps have a “Report a bug” menu item that will take you to the right place automatically. However two prominent ones did not: System Settings and Plasma. In System Settings, the menu item took you to the generic product, not the specific component for the page you’re on. And Plasma had no functionality like this at all.

That’s fixed now! As of Plasma 5.27, System Settings’ hamburger menu now has a “Report a Bug in Current Page” menu item that will take you to exactly the bug report URL for the page you’re on:

And in Plasma, plasmoids’ About pages now have a “Report a Bug” button that will likewise take you straight to the right place to report a bug on that specific plasmoid:

There’s more to do, of course:

  • Make the new “report a bug” category page in Bugzilla prettier with some better CSS
  • Also include along the user’s Plasma version and distro in the URL so that those fields on the web page can be pre-populated
  • Also implement this stuff for KWin effects and scripts, which an have their own Bugzilla components

Assistance with these follow-up tasks would be appreciated.

And regardless, now there is no excuse; go submit bug reports whenever you face a problem! 🙂

Published by Nate

Published

41 thoughts on “Making it easier to submit bug reports”

  1. Great news! Also will be good to improve an issue body text composer in Bugzilla, to allow some tags and styling – at least code blocks, bold/italic (maybe using MarkDown syntax?), and will be good to have inline images!

    Like

    Reply

    1. These are much-wanted features!

      Alas we can’t add them ourselves. They were supposed to be included in the next version of Bugzilla, but then that version lost most of its development team at Mozilla, so it’s plodding along slowly as a community effort now. Once it’s released, we can upgrade to it.

      Like

    2. We can wait a new release of Bugzilla very long time… Meanwhile, KDE developers seem moving all code workflows to GitLab, so maybe start moving Bug tracking to it too?

      Liked by 1 person

    3. Unfortunately, gitlab cannot be used as a bug tracker for kde right now, because it does not support moving bugs from one project to another. Its current implementation just copies the bug report.

      Like

  3. really necessary to clean this up.
    I still have the impression, that we could do more, especially in pages like ‘framework and libraries’ or ‘plasma’. Can we guide a person who does only work with plasma/kde to te right topic? How is he/she supposed to chose the proper entry?
    Yes, there is a ‘i don’t know’ entry, but this shifts the work to the guys reading bugreports and do load them with sorting out what this topic should go into (not sure if this is that much welcome)

    Moreover, the biggest obstacle for me would be feedback. Like, you add a bug report, and if this isn’t currently a hot topic, this means it can easily take weeks until you hear back from devs. (this is no complaint!!, i know how this works internally). But, for a typical user, the impression might be…. well, so they don’t care and why should i open another/new bug report then if this one gets neglected?

    Like

    Reply

    1. Are there special people working on bug traiging? That could maybe help get the feedback time down. For example, people can see if the bug report has enough information and try to replicate it.

      Like

    3. I still have the impression, that we could do more, especially in pages like ‘framework and libraries’ or ‘plasma’. Can we guide a person who does only work with plasma/kde to te right topic? How is he/she supposed to chose the proper entry?

      In the first draft, the description for "Frameworks and Libraries" had text saying "Only file a bug report here if you're a technical expert," but I removed it as it seemed kind of unfriendly.

      It's not a problem if people file a bug report in the wrong place as it can simply be moved. But the idea behind this was to make it easier for people to pick the right place. For for example if a person has a problem in Plasma, the "Plasma" group should attract their attention and send them to the right place. If their bug report is actually traced to an issue in a framework, the bug triagers or developers will move it there. It's not up to non-technical users to guess this correctly.

      Like

  4. Appreciate the effort that goes into these kinds of things, however I think the KDE community should ditch what I assume is bugzilla and choose something else or develop their own. It looks really out-dated and clunky. What do you guys think?

    Like

    Reply

  5. That’s really, Really, REALLY good news 😀

    (this will probably generate even more bug reports, but then again, once that – still cooking – “Reset Plasma” feature gets out, i believe it will help a lot on reducing some of bug reports)

    Liked by 1 person

    Reply

  6. I wonder where’s the old bug creation assistant?
    I remember in KDE SC 4.x it wasn’t just a link to Bugzilla.

    PS: Please fix the reply function in Bugzilla Emails..

    Like

    Reply

  7. Hi Nate,

    It’s great that you make it easy to report bugs, but what’s the use of reporting bugs once submitted bugs have not been fixed?

    The bug records that I have reported and have been open for an average of 2 years:

    https://bugs.kde.org/show_bug.cgi?id=422392
    https://bugs.kde.org/show_bug.cgi?id=418134
    https://bugs.kde.org/show_bug.cgi?id=418003
    https://bugs.kde.org/show_bug.cgi?id=418131

    To be honest, even though I see an error when I see this table, I don’t want to report it. Because; I’m not getting any results anyway.

    Like

    Reply

    1. We currently have 27,000 open bug reports and limited resources to fix them. So filing a bug report doesn’t guarantee a quick fix. But not reporting a bug guarantees that it *won’t* be fixed, unless someone else reported it too.

      The bug reports you’ve linked to are all fairly low priority compared to things like crashes and broken functionality, which explains why they’re not fixed yet. We need more development resources. Maybe you could help out?

      Like

    1. You don’t. You automatically get emailed about changes to bug reports you create, even if you’re not in the CC list.

      Like

    1. Yep that’s what I hat in mind! I’m pretty useless at web stuff though, so it would be great if someone else volunteered for this. 🙂

      Like

  11. Thank you for that. This will help solve part of the problem.

    One of the other problems that sometimes prevents me from reporting a bug in some KDE software or even trying to solve the problem myself is the impossibility of being able to find out in a simple and exact way what exactly the real name of the software is and/or the your command

    For example, I use KDE Neon with Brazilian Portuguese translation.

    Let’s suppose I want to open “System Monitor” and find out the application’s real name.

    As a non-advanced linux user, I would open “Monitor do Sistema” (System Monitor), look for the “Sobre o Monitor do Sistema” (About System Monitor) button, and try to get the real name of the application.
    The about page shows me a lot of information, except what I really need.

    Some things get in the way. On this page I only have the application’s name translated into Brazilian Portuguese, which may not necessarily be the same or even minimally similar to the name used by core developers to refer to it.
    I don’t see the command name either, i.e. I expected to see plasma-systemmonitor somewhere.

    Another problem, I have two different software that appear with the exact same name:

    plasma-systemmonitor and ksysguard

    In Portuguese, both are named “Monitor do Sistema”, so it can be very confusing.

    Like

    Reply

    1. The fact that bug reporting requires English, and the English name of the app may be different from the localized name, is indeed an issue.

      However there’s an easy solution: don’t try to find the app on https://bugs.kde.org at all, and instead use the “Report a Bug…” menu item in the app itself. It’s right there in System Monitor’s hamburger menu. This will take you to the right page automatically.

      Like

  13. I’ve reported about a dozen bugs over the past 3ish years. About half sit untouched, ~4 more sit unconfirmed because they could not be recreated despite me posting screenshots/videos of it happening, and 2 have been confirmed and remain unfixed.

    I’ll continue to report bugs as I find them. I try to confirm it is a reproducible bug and I’ll post steps how to do it with video and pictures, but I have yet to post a bug that gets fixed.

    Like

    Reply

    2. Don’t give up! Even if you file a duplicate, because you didn’t know that there was another report already filed, this isn’t bad, but it has the same effect as if you added yourself to the CC: It shows that it affects more people and thus raises the priority in a way.

      Liked by 2 people

    4. I’ve created many duplicates, as the words I searched for didn’t find existing bugs. This is a failing of the search system. Especially as non-insiders won’t know the magic words the techies use.

      Like

  15. This is awesome!

    In general, KDE quality is amazingly good. Recently, Ive been trying to confirm bugs and do some basic triaging. But most of the reported issues seem so esoteric, with no bearing to my usage at all, so usually have to skip > 80-90% of reported issues with no way to confirm. Oh well, i tried. 🙂

    Liked by 1 person

    Reply

    1. Yep, that’s a common experience. The basic stuff mostly works very well (with a few exceptions we’re working on), but the more you customize and tweak the system, the more likely you are to run into esoteric bugs. It’s just the nature of a heavily customizable system, I think. In the end we need more developers who are using these settings, who can fix the weird corner case bugs they expose. Until then, maybe we need to do a better job of managing expectations?

      Thanks so much for helping out with bug triaging! It’s much apprciated.

      Like

    2. This got me thinking: is there any way (or a possibility to implement a system) to export al of your configurations in an anonymized, form so a triager or developer can apply it and try to reproduce the bug in sort of the same environment as the reporter?

      Hope I made myself clear, english is not my native language.

      Like

    3. It’s an interesting idea. Would be quite technically challenging. But even just knowing what customizations and 3rd-party apps/scripts/effects/etc the user has installed can be helpful. We could perhaps make a thing that exports this information in a way that the bug reporter can consume.

      Liked by 1 person

    4. Good point, I didn’t even consider that the user might be using third party themes/icons/etc, which would be harder to automatically replicate.

      But yeah, the info could be useful.

      Like

  16. This is a great help for non-IT people. One less barrier for us trying to guess which product.
    Lets hope that more bugs from the non-IT point of view, begins to affect KDE software in general.

    Like

    Reply

  17. Will effect debug symbols as well? Everytime I tried to report a bug I always ended with problems generating a good backtrace. Even downloading those debug symbols most of the time (at least for me) didn’t ended with a complete bug report. Lately everytime Dr Konqui show up after a crash I just ignore it and move on.

    Like

    Reply

Leave a comment