Hello, KDE bug tracker has a problem, it’s not good for 5 seconds of bug filing. Which, believe me is not a second longer than a casual user wants to give. I know there are a lot of volunteers working for hours upon hours to make KDE project happen, so what is a minute from the users life, right? Well unfortunately that’s not how some users work. Users need to; create an account with my email > find the right category (which most new users don’t even know what to look for) > search for existing bugs > write a short essay > wait.
I don’t think changing how KDE bug tracker works is a good idea, but a “quick and dirty” alternative is needed. For example this alternative can have lesser focus from KDE developers. This way, despite having duplication issues more people will be willing to submit bug reports. In this alternative page we can incentivise the user to use the original bug tracker but not force them to do so.
And this is the main problem basically because those users are not really helping when all they report is useless noise that waste developers’ and bug checkers time because they don’t ever read how to write useful and confirmable bug reports according to the guidelines:
If you can reproduce occasionally, but not after following specific steps, you must provide additional information for the bug to be useful.
If you can’t reproduce the problem, there’s probably no use in reporting it, unless you provide unique information about its occurrence.
Make sure your software is up to date. Ideally, test an in-development version to see whether your bug has already been fixed.
When reporting a bug, first check if you can reproduce the bug in a new profile. If the bug only happens in your existing profile, try to figure out what [settings, extensions], or [files in your profile] are needed to reproduce the bug.
If the bug seems egregious (i.e. obviously affecting a large portion of users), there’s probably something unusual about your setup that’s a necessary part of the steps to reproduce the bug. You have much better chances of figuring it out than a developer who does not have access to your system.
If the bug falls into one of specific types of bugs listed in a section below, it may still be useful even if you can’t reproduce it in a new profile.
If you have multiple issues, please file separate bug reports.
The amount of bad and useless bug reports (often support questions in reality) is unfortunately endless in the bug report tracker.
Hmm interesting, I wasn’t aware of that problem, what I suggest can filter those out too though. Like I said people willing to give the required info can be focused on first. And this alternative bug tracker can be looked at afterward.
Not really - or not in a good way. First off it would mean that more people use the bug tracker that isn’t very helpful, instead of the complex one. And second, a huuuuuuge part of this is bug triaging. Basically someone going by bug by bug by bug - trying to recreate the bug, merge bugs that are the same, move them to the correct area, try to fill out more information etc.
With a simpler system that would be even more work for them and the work would be way harder.
(I think KDE should do a Bug Squashers Academy event with training for people to help triage bugs since right now, sadly its often done by devs - taking away their time to actually fix bugs)
The reason for the account is basically because if someone pick up that specific bug, they may need to ask if a fix is working or look for more info - many bugs are closed because people make an account and then don’t reply. Having no account at all would make it almost impossible to fix some bugs.
Same with the huge amount of info (although I thought Dr Konqi helped with that at times). Sometimes or rather MOST of the times, bugs are specific to a distro or a specific set up. Without knowing that you’re going in blind and the chance of fixing a bug is way smaller.
I don’t wanna sound like a debbie downer obviously. I think everyone knows what you mean, filling out a bug seems so fiddly at first. All those subcategories and all that info, but it gets easier each time. And yes, you are totally right its very difficult for new users to get in to.
The problem is that its a hard complexity to get around because when you make it easier at one end, suddenly it gets harder in the other.
(Also I thought, I don’t know, but that Dr Konqi would spit out eventual crash reports with all the info to use? Again, I have no idea so that was just my assumption - and it only covers crashes I suppose)
And here comes the usual questions that comes up every time someone proposes something new in a free world: who’s gonna create, test and operate it? Are you willing to help on implementing your idea?
PS: I hate to be that, but someone has to ask these questions, because unfortunately you can’t can the stuff you want for free without you getting involved.
I agree with the others. If you can’t spend 5 minutes filling a bug it is better to not report it at all. Better ask in a support forum or ask your distro for help.
Additionally Drkonqi can now automatically create crash reports for those users that don’t want to file a bug report.
Thank you for the replies everyone, I have learned different perspectives and ideas from everyone! Except for you @jsalatas! Naa na, I’m just joking around For being real, I used to report bugs in late 2010s era, but I have stopped using KDE for a while, when I came back in 2023 I couldn’t find anything to report about. And all wanted to do was to create a gate for newcomers. KDE slowly but surely becoming a sizable operation and with more adoption (like hopefully fedora as default) I truly believe the user should be prioritized. Of course, from what I learned from this thread, seems like that time is not right now. So let us hope for wider adoption and a 1 million dollar donation from foreign donors.
I’m filling some bugs from time to time, and the function that really needs to be improved is the suggested list of “Possible Duplicates” that you get while filling the bug content.
That list is surely not showing all related bugs, which why I learned to perform an advanced search before starting the creation of any bug.
This problem is the prime source of wasting time for KDE devs, because verifying bugs is not an easy task, they need to read, understand, search for duplicates, before attempting to reproduce and finally deciding the bug status.
The elephant in the room is that the faster you wrote the bug report, the most likely it is to be useless garbage that wasted everyone’s time. Junk bug reports take forever to triage, and are likely to not be actionable, meaning the effort spent reporting it amounts to nothing as well. Nobody wins.
If you write a good bug report that’s actually actionable, that takes time. The more time you put into it, the more likely it is to be actionable.
If you can’t spare that time, you can always post about it here, or spend 20 minutes writing a rant on Reddit or 8 hours creating a 30 minute YouTube video about it. Those are definitely effective and positive uses of that very scarce time that people who can’t spend 5 minutes to write a decent bug report oftne say they have!
To illustrate this, according to today’s timesheet at work, I spent 5.7 hours triaging KDE bugs today, spanning the bugs reported today as well as from March 12 through March 16th (I’m in catch-up mode!). During that time, I found I think 7 or 8 that were actually real bugs or valid feature requests. Most were very minor. The other 100+ were:
Duplicates of existing bug reports, some of which were fixed months or years ago
Actually bugs in 3rd-party apps
Actually bugs in miscellaneous 3rd-party libraries, like PipeWire, Bluez, or Libinput
Actually bugs in the Linux kernel or device-specific kernel drivers
Actually bugs in GPU drivers
Complaints about an intentional design choice that’s a matter of opinion and not actually a functional, visual, or usability issue
Either bereft of information or borderline incomprehensible, requiring lots of back-and-forth to even figure out what the reporter is trying to say (these are by far the worst).
Dealing with bad bug reports takes an enormous amount of time that isn’t spent on actually fixing or developing stuff. I have zero interest in making it easier for pepole to submit low-effort bug reports.
The only thing I would change if it would be possible is to make wishlist “bugs” somehow more visually distinguishable in order to “filter” them out, and additionally an option for them to be excluded in searching/browsing (unless I’m missing something there).
One thing I’d like is the ability to always group (not sort) Bugzilla tickets by severity. So no matter what sort mode I chose, the CRITICAL bugs would always be in a group at the top, then there would be some whitespace, and then the GRAVE bugs, then some whitespace and then the MAJOR bugs, etc, all the way down with the WISHLIST bugs all the way at the bottom.
I’ve submitted a few bug reports. I tried my best to check whether there was a duplicate bug report already, but I ended up creating one anyway and it was soon marked as a duplicate by Nate (probably? I don’t remember).
I would really like better search experience in the bug tracker, somehow. I can’t figure out how to search properly and efficiently, and I spend a fair amount of my time on Jira during the week reporting and triaging bugs for my job.
The only successful way I’ve been able to find issues I know already exist on the bug tracker is to use a search engine to find a wiki article that talks about the issue and links to it. I spent maybe 15 minutes trying to find whatever the Wayland issue was for Krita and just gave up, instead finding it linked to on krita-artists.org
If the search was better, I would probably prefer the experience to Jira.
This is does not sound like state of the art bug tracking.
I do mobile and web apps and it could be like 15 min - 60 min a week to go thru the bugs. There are tools like Firabase Crashlitics, Sentry, etc…
It mostly works that users do actually NO effort at all, everything is automatic to us devs to get value. Issues are categorized by stack traces, device info, u name it. U can see count of occurrences of same issue. You can sort by that and fix by something which is very close to what users need.
I can imagine there is no solution like this (and I am not gonna do created ). I can see there will be more obstacles due to distros fragmentation. Just wanted to point out it could be better and more time effective.
Do you thing tools like this would improve the situation? Or is it to hard to solve issues like getting proper debuginfo and automate this and it does not worth the effort?
The amount of bad and useless bug reports (often support questions in reality) is unfortunately endless in the bug report tracker.
For being real, I used to report bugs in late 2010s era, but I have stopped using KDE for a while, when I came back in 2023 I couldn’t find anything to report about. And all wanted to do was to create a gate for newcomers. KDE slowly but surely becoming a sizable operation and with more adoption (like hopefully fedora as default) I truly believe the user should be prioritized. Of course, from what I learned from this thread, seems like that time is not right now. So let us hope for wider adoption and a 1 million dollar donation from foreign donors.
). I can see there will be more obstacles due to distros fragmentation. Just wanted to point out it could be better and more time effective.