Bug triaging is a largely invisible and often thankless task. But it’s the foundation of quality in our software offerings. Every day, our users file between 30 and 50 bug reports on https://bugs.kde.org, and often up to 100 right after a big release! Many will be duplicates of pre-existing issues and need to be marked as such. Quite a few will be caused by issues outside of KDE’s control and this also needs to be marked as such. Many will be crash reports with missing or useless backtraces, and their reporters need to be asked to add the missing information to make the bug report actionable. And the rest need to be prioritized, moved to the right component, tagged appropriately, and eventually fixed.
All of this sounds pretty boring. And, to be honest, sometimes it is (I’m really selling this, right?). But it’s critically important to everything we do. Because when it’s not done properly:
- Users don’t feel listened to, and start trashing us and our software on social media.
- Critical regressions in new releases get missed and are still visible when reviewers check out the new version, so they also trash it in high-profile tech articles and videos.
- Un-actionable bug reports pile up and obscure real issues, so developers are less likely to notice them and fix them.
- Bugs that occur over and over again don’t accumulate dozens of duplicates, don’t look important enough to prioritize, and therefore don’t get fixed.
- Easy-to-fix bugs don’t get fixed by anyone and it’s pretty embarrassing.
Do you see a pattern? Most of these results end up with KDE software being buggier and KDE’s reputation being damaged. It’s not an accident that KDE’s software is less buggy than ever before that that we enjoy a good reputation today. These positive developments are driven by everyone involved, but they rest upon an invisible foundation of good bug triage. And as KDE software becomes more popular, users file more bug reports. So the need for bug triage constantly grows. Currently it is done by just a few people, and we need help. Your help! And it will truly be helpful! If you are a meticulous, detail-oriented person with some technical inclination but no programming ability, triaging bug reports may just be the best way to help KDE. If this sounds like something you’d like to get involved with, go over to https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging and give it a read! I would be happy to offer personal bug triaging mentorship, too. Just click the “Contact me” link here or at the top of the page and I’ll help you get started.
Adventures in Linux and KDE 
I read only the first sentence, but can put my sign below. Well said! 🙂
LikeLike
Fully agree with you, Nate! However, to improve the situation, an enhanced, better working search and more overview in bugzilla over all the products and components would help a lot to find possible duplicates, before filing a bug and also to triage bugs.
If I didn’t bookmark bugs important to me, I’d have a really hard to find them again unfortunately and sometimes I don’t see that a bug report already exists and then by accident create another one until one of the bug triages stumbles over it (magically). 🙂
LikeLike
To see the bugs you filed, click on the “My Bugs” link in the bottom-left corner of the window on the homepage.
I know that the Bugzilla’s UX is not the best but I don’t find it unbearable. What are the problems you find with the search? I find that it works all right.
LikeLike
> To see the bugs you filed, click on the “My Bugs” link
But only those whose status is reported or confirmed; all other’s are filtered out and one needs to modify the url parameters to see all, closed, needs info, etc. unfortunately.
> What are the problems you find with the search?
I don’t like the interface especially. 🙂 Let’s take a look at the advanced search: https://imgur.com/a/XIPwsIq
You have a huge list of products and components, but you don’t have a search field, to filter these long lists. One can of course just start typing right away, but blindly typing or scrolling is less fun.
Let’s say we want to search for something but we are not sure, where it may be hidden.
E. g. what’s the product “Active” for example? Is this a product I should include? What is it about?
Even we go to https://bugs.kde.org/describecomponents.cgi where the products are explained: It’s a huuuuge list and not everything is directly clear. I’d wish this list were transformed in some list of categories with items, including some visual hints like screenshots if appropriate and for non-experts some more explanations or guidance added.
Back to the search, maybe you want to search in multiple products at once then you can select multiple entries with ctrl or shift. However, then the component list becomes even longer. If you click accidentally at a random place, all your selections may gone in the worst case. Here a second box could be useful, where you select and add/drop items you want to include in your search.
Another problem: Those list boxes are unnecessary very small for the amount of items they hold.
There may be more points which bug me (pun intended), but I think you may get an idea. To sum up, it’s usable, but it could definitely be improved. I hope my points are somehow valid. 🙂
LikeLike
I won’t defend Bugzilla’s UX. It’s something you get used to over time, but yes, it could be better.
LikeLike
In addition, many of the components listed are just obsolete. They should just be removed.
LikeLike
If we did that, we would have to delete all the bugs in them, and would therefore lose history. If we hid them from the UI without deleting them, we would lose the ability to access that history. Closed products are already hidden from the view you see when filing a new bug report, it’s just that they’re not hidden from everywhere. It would be good to move closed components elsewhere visually from the views in which they are not hidden, but simply deleting them and their history is not the answer.
LikeLike
> If we hid them from the UI without deleting them, we would lose the ability to access that history.
Are those still relevant? Couldn’t those be moved to some sort of archive?
LikeLike
If Bugzilla offers such a feature, then yes, that would make sense. I don’t know if it does, though.
LikeLike
“If we did that, we would have to delete all the bugs in them, and would therefore lose history. If we hid them from the UI without deleting them, we would lose the ability to access that history.”
Is that really a problem given the products are obsolete? Why keep bug history for all those products which are long gone and no longer maintained?
LikeLike
Losing history is always a problem in any long-lasting institution that accumulates knowledge, experience, and wisdom over time. Those who forget history are doomed to repeat it and all that. 🙂
LikeLike
“Losing history is always a problem in any long-lasting institution that accumulates knowledge, experience, and wisdom over time. Those who forget history are doomed to repeat it and all that.”
Unless it looks like something out of an episode of Hoarders…
LikeLike
Maybe it’s time to move to Gitlab issues
LikeLiked by 1 person
Unfortunately GitLab issues lacks many important features of Bugzilla, such as multiple resolution statuses, a “number of duplicates” counter, bulk updates, a “version reported against” field, global templates/tags/milestones/priorities (right now they are per-repo), blocking/blocked by markers, allowing reporters to categorize and tag their own bugs, the ability to have bug reports unconnected to a particular repo (where would all the `plasmashell` bugs go?), a powerful advanced search…
I used to be more in favor of moving to GitLab because of its better UI for reporting bugs, but the more I looked into it, the more I realized that it would be a nightmare for bug triagers and developers of anything except apps where there is a 1:1 mapping of repo to bug report.
LikeLike
Sometimes I think even some fresh coat of paint in the form of a custom CSS, would greatly help Bugzilla be more friendly to use.
LikeLiked by 1 person
I’d like to second that! 🙂 Carl Schwan, have you heard? 😛
LikeLike
It exists, but unfortunately the release has been delayed for years: https://github.com/bugzilla/harmony
If you want to help, please join #bugzilla in Libera Chat.
LikeLiked by 1 person
I heard a rumor that Mozilla fired the entire team working on it, leaving it basically community-maintained. Do you know if this is accurate or not?
LikeLike
Can’t seem to be able to reply to Nate, so replying to myself.
Dylan was gradually working on the harmonisation while he was employed at Mozilla. He was not fired as far as I recall (went to work for Fastly). It is true that two employees working on Mozilla’s instance were let go.
Dylan has continued the work on the harmonisation on his free time, supported by other volunteers. The number of remaining tasks before release is small, but Dylan’s time is rather limited. I hope us at TDF could test Postgres with Harmony.
Dylan’s task list: https://gist.github.com/dylanwh/63499d130b3de16620b0928f76e4d37b
The work on Mozilla’s instance can be observed here: https://github.com/mozilla-bteam/bmo
LikeLike
It’s good to hear that the effort isn’t dead. Maybe KDE people with relevant skills could participate too. Because it seems like a next-generation Bugzilla with a better UX is really our only practical path forward at this point.
LikeLike
Although I understand the rest, why do you need “number of duplicates”?
LikeLike
It helps developers understand how many people are experiencing the bug, which helps with prioritization
LikeLike
People who care about bugs will overcome any obstacle to care about bugs. People who excuse themselves from doing the bug work will continue to find excuses.
Tooling changes can make some aspects slightly easier – but the only magic bullet is more people.
LikeLiked by 1 person
So much this. 🙂
LikeLike
I agree with all this Nate. But bug triaging is one part of the foundation of quality, and there’s more than meets the eye. I believe this is a great example of “less is more” sometimes.
The KDE suite is extensive, and it doesn’t seem like it has to be. The KDE Plasma desktop itself has a lot of features which I would be surprised if users actually know about or use (rotating widgets?).
Sifting through all the products to find the one you’re looking for, then sifting through all the categories, then sifting through all the components, “what are these ‘Flags’ things?”, etc. The poor user reporting the bugs is confused as to what to select, and the poor souls triaging the bugs now has to work out whats going on.
Perhaps KDE is getting a bit obese, in terms of sheer workload. I was amazed when I came to Plasma how many KDE applications there are, where other applications do better. I have mixed feelings about this: having them all as KDE apps makes good opportunities for integration and a potentially great UX, but at the same time, why duplicate what is better covered by other apps?
Perhaps a survey of users is in order to determine which apps, components, features, etc are seeing little to no use.
Perhaps take a break and have a release cycle focused on bug fixes every once in a while to clean the queue. There’s no harm in the occasional release that doesn’t add significant features, but users will appreciate it if many bugs are fixed. New features can be a beast to test and verify.
Another part of the foundation of quality is to keep the focus alive. I have occasionally noticed that KDE likes to engage in things such as politics and focus on causes that have nothing to do with KDE software. This ties up valuable resources that could be used for quality control, and puts potential (and existing) users off. Drifting away from a core focus ensures the quality goes down.
All that said, I’ve been pretty happy with how KDE is going. Immediately after every release, I think “Right, I’ve got what I needed, no need to be too excited by the next release.” Then the next release happens and implements or fixes something I like…
LikeLiked by 1 person
You’re not wrong that our eyes can be a bit bigger than our stomachs when it comes to software. We’ve written a lot of software–which is fun–but the more code, the more maintenance burden–which isn’t fun. Down the road, when the fun of coding is over, the pain of debugging and bug fixing remains.
The thing is, KDE doesn’t have a central committee that determines things where to allocate personnel resources or what apps to develop or drop. Let’s imagine we ran your proposed survey and it turns out that most people say they don’t use App X. What if that app still has an active volunteer maintainer? Do you tell him, “Sorry, the community has spoken, we want you to stop working on App X and work on App Y instead.” Of course not, that would be absurd. It’s not how volunteer communities work. Resources can’t just be shifted around like that. People doing Thing X does not imply that they could be put to better use doing Thing Y instead; if they wanted to do Thing Y they would have done it. And if Thing X is somehow prohibited, they won’t do Thing Y instead; they’ll do nothing, or generate negativity about being prevented from doing Thing X.
The bottom line is that KDE doesn’t work like a big hierarchical company with bosses who tell people what to do and upper management that determines the overall direction and shifts resources to achieve goals. It’s not what we are, and it’s probably not what we could ever be. Motivating volunteers requires a different approach.
FWIW Plasma 5.22 more or less was a “bug fixes and polish” release. We didn’t do a lot of feature work and focused on improvements, especially to the Wayland session.
LikeLiked by 1 person
Sure, if their maintainers want to work on these things then sure, why not?
I should have clarified what I meant. With the survey, I was considering volunteers that are just maintaining things because they feel obliged to. It is more so the maintainers who are tiring can decide whether to continue or not. Occasionally it happens when maintaining a piece of software turns from fun to obligation.
Of course with the core Plasma desktop such a survey might focus on features instead of apps or specific KDE projects, but a similar situation applies.
So such a survey would be a tool rather than a policy.
LikeLiked by 1 person
Maybe the lack of a strong driver behind the KDE development is part of the problem that KDE suffers from. Obviously, a central committee is of no use if it doesn’t have resources (read manpower) to allocate to the various projects. I see that certainly as an advantage of the Gnome DE where Red Hat sponsors a core developer team to work on Gnome and drive its development (obviously to a direction that is useful for Red Hat, but I feel that’s alright as it most likely ensures the quality remains high as well). Those are certainly not the only Gnome developers, and probably not even the majority, but I feel it helps the project to have a core team with a clear vision of what the final product should look like, and the resources to action this.
Don’t understand me wrong, I am all for diversity and I love the flexibility of KDE which is why I have been using it for over 15 years as my primary (only) desktop environment. However, every upgrade to a new release is a huge gamble in terms of stability and usability. With every upgrade in the past 5 years I encountered new (or old) bugs, some of which have been extremely annoying and all are reported in the bug tracker! I feel that if there was a bit more clear focus on the core components that are tested thoroughly before every release, then there would be less of those annoying bugs.
For instance, with Fedora 34 (KDE 5.82 / Plasma 5.21) I gave Plasma on Wayland a spin, just to realise that it is a half-baked release with many bugs that prevent me from using it in a production environment (especially the clipboard issues listed here: https://community.kde.org/Plasma/Wayland_Showstoppers). But also when switching back to X11, there are still things that are simply broken, e.g.:
https://bugs.kde.org/show_bug.cgi?id=390295#c7
In fact, it appears KDE’s session management is unmaintained and bugs are just piling up. The above bug report outlines an issues that has been broken and “fixed” several times over the past few years, while it is currently still broken. Other examples are:
https://bugs.kde.org/show_bug.cgi?id=392375
https://bugs.kde.org/show_bug.cgi?id=374154
https://bugs.kde.org/show_bug.cgi?id=320561
https://bugs.kde.org/show_bug.cgi?id=263932
From this list, the first two are fairly recent, while the latter two are very old and there is a good chance that they don’t even apply anymore – still they remain unresolved in the bug tracker.
Now, I don’t have the capacity to contribute actual code (GUI development is anyway not my cup of tea), but I will certainly check out if I can contribute in triaging bugs and very much appreciate your article in this regard.
LikeLike
There is sort of a core team paid by Blue Systems (my employer) to work on Plasma, but it’s quite small, especially compared to the size and scope of Plasma. Ultimately like I said, bug triaging is the foundation–not the whole house. Well-triaged bugs don’t fix themelves, and in the end more people helping out on code is what’s required. On that front, the two options are basically to pare down your ambitions to match your resources, or increase your resources to match your ambitions. The former will not really work for KDE because all those features and customization opportunities are exactly what people love our software for. If we remove them to make the core more maintainable, we would become a cheap, pale clone of GNOME (this was what they did). To keep our uniqueness, we need to do the opposite thing and get more people helping.
Thanks for offering to help with bug triaging; I look forward to working together!
LikeLike
“Sifting through all the products to find the one you’re looking for, then sifting through all the categories, then sifting through all the components, “what are these ‘Flags’ things?”, etc. The poor user reporting the bugs is confused as to what to select, and the poor souls triaging the bugs now has to work out whats going on.”
I concur with this! In fact, this has kept me from filing bug reports for some of the minor issues I encountered. It is sometime simply to hard which component is responsible for the issue at hand. This is especially difficult with everything that is happening in the panel/system tray.
If it was possible to report a bug straight form the actual software/component that would probably be ideal as it would allow also to gather the relevant software versions and other information…
LikeLike
You can always file under the generic “kde” component and it will be moved appropriately by a bug triager.
It is, at least for most QWidgets apps. Help menu > Report a bug.
LikeLike
Well, I think the “reporting it under the generic kde component” is what we should avoid to make the life of a bug triager easier. 🙂 But I agree, better that way than not at all.
I otherwise agree, reporting bugs from within most (all?) modern KDE application via the “Help->Report a bug” menu works pretty well – thought also there is some room for improvement. For instance, there are those bash screenshot information tools (e.g. https://github.com/KittyKatt/screenFetch) which manage to pull out a whole lot of information from a system including all sorts of hardware and software version numbers as well as information regarding the desktop environment. This is super handy when reporting bugs! However, the bug reporting utility doesn’t seem to do any of that and leaves it to the user to gather all that information, which can be quite tedious and could/should be automated. Come to think of it, I should report this as a bug/feature request in KDE’s bug reporting utility… but that brings me again to the point that I don’t even know which “product” or “component” this belongs to. The list of products on https://bugs.kde.org/enter_bug.cgi is sheer endless.
Also, while the “Report a bug” menu is a very good starting point and sets the user to the right direction, this doesn’t work anymore with bugs in kwin and the plasma-shell. Especially kwin is a major pain since this is a key component of the KDE desktop and plagued with a lot of severe bugs for years! Those are the kind of bugs that are most visible to users and leave them somehow helpless as it’s not any particular application that doesn’t work and navigating through the KDE jungle of which “product” is which is daunting especially for the less tech savvy users. I guess my point here is that while I figured this out more or less over the years (also because I am fairly stubborn with such things), it should not be that hard for an “average” user.
Just my 2 cents.
LikeLike
Having the bug reporting tool that’s built into apps pull system information is a great idea. FWIW the code for it lives in “frameworks-kxmlgui”, so you could report it there.
But really there is no good solution to it being hard to find where to report bugs. If we moved to GitLab issues, for example, would it be any easier? No. This would not help you at all to figure out that the code for the thing you’re reporting a bug on lives in some framework. You would probably report it against Dolphin or whatever, and that someone would manually move it to the correct place, just like they do now. 🙂
This is why it’s okay for people to report bugs to the generic “kde” product. It’s better to report a good bug to the wrong place, then to not report a bug at all because you can’t figure out the exact technically perfect place to put it.
LikeLike
One thing that I find surprising is that even using KDE Neon (latests versions and developers desired config for the environment, apps, etc), when an app crashes (last one I think was discover) and shows the bug trace wizard, is not possible to install all the development packages to produce a valid reverse trace. There is a button in the wizard to install the needed dependencies, but several ones cannot be installed because the proper package cannot be found (always something qt5 related). If this happens in KDE “official” distro, how can the situation be in others.
If I am willing to assist creating a valid and useful bug report, but can’t because I cannot install the proper tools, maybe this is something that can be prioritized
LikeLike
It would be great if more distros like Arch and Ubuntu started using debuginfod, https://sourceware.org/elfutils/Debuginfod.html
LikeLike
Yes you are right, it often happens to me on Neon and then I end searching which package have the dependency needed by hand.
LikeLike
A few comments from a Part Time Triager…
Don’t be scared away by the “Howto”, you don’t need the superpowers it seems to ask for 🙂
You need to understand what people are saying and take time for that. People come in with their own assumptions about how something works (should work) and treat of loads of info as “self evident”. They may be doing something that you’ve never imagined trying to do or stumbling over something so obvious to you that you’ve never stopped to think. You can sort out bundles of issues without needing to understand crash dumps…
It makes sense to focus on a product you know. You’ll be able to pass on your experience and also certainly learn from the issues that other people report. If you’ve been using a product for a while, you might also recognise “something” that was there six months or a year back and people with an older distro are still hitting…
The “can you reproduce” the bug is the “Ah ha!” moment. If you’ve found a way of reproducing the bug on a “clean” system and are able to describe the steps. That’s gold and, I’ll admit, a little addictive…
Don’t sweat over Bugzilla. You don’t need to provide 100% answers; you can find links and patterns and append them to the bug. Think that that work can help someone else get the next step closer. It is relatively simple to bookmark a search for a particular product so you can watch the flow of incoming reports…
The tricky bit for me was remembering what I had been trying to keep track of. There’s thread drift in reports and you can get a real gem about a different issue embedded in a long conversation. Finding that ‘amazing insight” again is sometimes a real challenge. I’ve started saving pages locally (they look a bit rough without CSS when you reopen them) but I find “free text searches” with baloo really useful when you start with vague and muddled recollections.
LikeLiked by 2 people
I love KDE and try to report bugs to make it better, and when I fill bugs I try to choose clear title (but still bad with english because it’s my second foreign language), but the duplicate table that appears at bottom doesn’t give me any similar bugs which will help me to know if the bug is already reported or not, so I know how it’s hard for KDE teams to search for duplicated bugs. It would great if KDE bugs could migrate to another modern platform which has more advanced triaging algorithms. Because the current look and provided functions are lacking : like removing comments, upload big files, view images and videos on the same bug page, provide pretty formatted code or logs.
LikeLiked by 1 person
Yes, those are all limitations of Bugzilla. I too would like to see improvement here, as it seems frozen in amber right now. However the tricky thing is avoiding the loss of things we currently do rely on. If we migrate, it needs to be towards something genuinely better, not better in some ways but worse in others.
LikeLike
I completely agree! Just to confirm here is the a little story from our work on Kdenlive: At the begin of the year we did a lot of bug triaging. The tracker was a bit orphaned, lots of duplicates, old reports, that have already been fixed in the past, but not been closed,… We were 1-3 focusing on bug triaging for a few weeks and closed more than 500 bug reports. Some of the valid bugs were very easy to fix and we just did that “by the way” so the stability of the app benefited too. Now we have less than 400 open reports (probably still a few that can be closed) and we regained the overview of the open bugs. The work was really worth it because as a consequence it is also easier to triage new bugs now, e.g. because you can find duplicates faster. Personally I added the atom feed to my news aggregator app to get notified on new bugs. This way I can triage them directly, the tracker stays clean and I have very little effort compared to the “sprint”…
However I have to admit, that – as tagwerk wrote – it makes the triaging much easier if you know (at least as a user) the app/software you are triaging bugs for.
LikeLiked by 1 person
So don’t ask the user to notify any idea he comments here or anywhere about KDe software. Reality is that the amount of the bug requests overwhelms the ability to face them. So to frustrate the developers as well as the same users are frustrated because of bugs and useless requests they notify. The risk is to disappoint expectations generating disaffection. Sometime users want just to know if some ideas are possible or not. But also in this case it seems a problem to answer by a simple yes or no.
LikeLike