Bug tracking vs user support

I often encourage people to submit bug reports when they complain about this or that on Reddit or comments here or wherever. This works as long as their problem is actually a bug.

But many problems are not bugs. They could be user error, a misunderstanding of the software’s scope or capabilities, a request for something impossible, a long rant about how the software sucks, or a request for help recovering the picture of their kawaii catgirl waifu that they just lost in Krita.

I’ve noticed that the more popular a product is, the worse the bug reports it tends to get. This makes sense, right? A niche product is used only by experts; a popular product gets used by 0-dots-in-computers users to whom bug trackers are weird and unfamiliar. It’s common for normal people to have difficulty describing a discrete technical problem in precise terms, or to bury the useful information in a description of their distant end goal or how the problem made them feel. Hard and jaded software developers who read such bug reports roll their eyes and cruelly wonder how their hapless users manage to plug in their coffee makers without electrocuting themselves.

But non-experts who are having problems with our software need help too! It’s just that the bug tracker isn’t the right place for it. What they need is user support.

This is where https://discuss.kde.org comes in. Discuss is full of magical people who are not only good at talking to other people, but also at understanding machines! These magicians can be the bridge between regular folks and software developers, providing technical support and filtering out problems that aren’t bugs so they never make it onto the bug tracker. They can also evaluate whether a problem is a bug and ought to be reported there.

So if you’re a happy KDE user, you can become a superhero by answering questions at https://discuss.kde.org/c/help/6! Help regular people recover their misplaced files. Explain to them that update errors in Discover are caused by their distro. If their issues seem to be real bugs, direct them to the bug tracker.

And if you’re having a problem with KDE software, and you don’t know whether it’s a bug or not, ask for help at https://discuss.kde.org/c/help/6. You’ll probably get a better response!

Making it easier to submit bug reports

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! 🙂

An easier way to test Plasma

Having the Plasma and Usability & Productivity sprints held at the same time and place had an unexpected benefit: we were able to come up with a way to make it easier to test a custom-compiled version of Plasma!

Previously, we had some documentation that asked people to create a shell script on their computers, copy files to various locations, and perform a few other steps. Unfortunately, many of the details were out of date, and the whole process was quite error-prone. It turned out that almost none of the Plasma developers at the sprint were actually using this method, and each had cobbled together something for themselves. Some (including myself) had given up on it and were doing Plasma development in a virtual machine.

So we put some time into easing this pain by making Plasma itself produce all the right pieces automatically when compiled from source. Then, we created a simple script to install everything properly.

So now all you have to do is compile Plasma and run this script once:

sudo ~/kde/build/plasma-workspace/login-sessions/install-sessions.sh

This will install all the necessary bits to make your compiled-from-source Plasma appear in the SDDM login screen’s session chooser. You even get both the X11 and Wayland versions!

Thereafter, you can just log out of your distro-provided Plasma session and log into your custom-compiled Plasma session whenever you want. It’s super easy:

There are a few quirks surrounding DBus and Polkit that you can read about on the wiki, but it totally works and now it’s super duper simple to test and use your custom-compiled Plasma without polluting your base system. I’ve been using the Plasma Wayland session from git master with no VM for my daily computing and development needs for the past three days and it feels *amazing* to be able to do this. Many thanks to veteran KDE developer Aleix Pol Gonzalez for this work.

So now you really have no excuse not to build plasma from source! 😉 Check out the developer documentation and give it a try!

Bugs.kde.org improvements

I’d like to share some welcome changes that we’ve recently made to https://bugs.kde.org, KDE’s venerable bug tracker. Improving our bug submission process was one of the ideas I submitted to KDE’s 2017 goal setting initiative, and while it wasn’t formally chosen the way the Usability & Productivity goal was, people seemed to think that it was worthwhile to do anyway. The overall task tracking this effort is https://phabricator.kde.org/T6832.

I’m pleased to report the following improvements:

First of all, we changed the names of some statuses:

UNCONFIRMED -> REPORTED. We observed that users got frustrated when bugs were in the UNCONFIRMED status after months or even years of being open, and would leave comments such as “Why isn’t this confirmed!? X number of people are experiencing it!” Hopefully REPORTED will inspire less frustration.
WONTFIX -> INTENTIONAL. We observed that the phrase “won’t fix” was rubbing people the wrong way because it was implying that we acknowledged there was a bug, but we just didn’t feel like fixing it, for unknown reasons. In reality, this was meant to communicate “the software is designed this way on purpose.” Hopefully INTENTIONAL will communicate this better.
INVALID -> NOT A BUG. “INVALID” felt a bit harsh and judgmental. What we wanted to communicate was that the bug was not appropriate to have been reported on the bug tracker because it was a support request, complaint, or something else that isn’t an actionable for fixing. “NOT A BUG” should do a better job of communicating that it’s, well, not a bug. 🙂

We also added a template to the text field you get when you file a new bug:

This should guide people down the path of filing better, more actionable bugs.

Speaking of filing better, more actionable bugs, we also changed the Bug Reporting Instructions link on the top of the page to point to https://community.kde.org/Get_Involved/Bug_Reporting.

Finally, we re-worked the attachment UI to no longer recommend attaching patches to bug reports (because they tend to get missed). Instead, it directs people to submit their patch using Phabricator:.

Hopefully these little improvements will lead to better bugs, fewer hurt feelings, and more patches. We’re already seeing a very good response from the new template in particular, and I’ve noticed that new bugs are being written following the template with Steps To Reproduce and version numbers. Awesome! This makes it easier for bug triagers and increases the likelihood that bugs will actually get fixed.

I’d like to offer a big shout-out to Andrew Crouthamel, who made all of this happen. Great job, Andrew!

Guest post: The Importance of QA

Today we have a guest post from Buovjaga, our friendly local QA evangelist for LibreOffice, KDE, Inkscape, Firefox and Thunderbird. Without further ado, I’d like to present…

The Importance of QA

With this post I hope to convince you that a strong quality assurance team can do miraculous things for a free software project.

The spectrum of QA is wide, and reducing the skill requirements is particularly relevant for KDE’s onboarding initiative.

The critical phase of onboarding a new contributor is the first contact. Sometimes the new person does not know what they want to do. Often you do not have a clear picture of what skills they have. You need to act fast or they will lose interest and disappear! This is the moment where you should hand them snacks: a query of bugs that need to be confirmed or re-confirmed. This is the lowest threshold for them to step across and into being a contributor, because:

They do not need to learn version control
They do not need to learn the patch submission processes
They do not need to be wordsmiths
They do not need to know interface design or how to draw pretty pictures
They should not even need to know how to use the features they are testing, because a valid bug report includes clear steps on what to do!

QA is highly important in itself, but it is also a gateway drug. A simplified story of the evolution of a contributor might be as follows:

They work on something meaningful
They get familiar with the structure of the project
They discover their own potential and the multitude of things they can help with

Not only does this evolution flow naturally through the QA team, but the experienced members are in a unique position to speed it up. This is because QA in the course of its work typically has to ferret out information from all the other teams. This leads to QA

Knowing who the subject-matter experts are
Discovering weak points in the organisation
Helping the various teams stay in sync with each other

In this aspect QA is acting like neurotransmitters in the body of the project.

The most apparent beneficial effect of having a strong QA team is that the developers are not distracted by massive amounts of first-stage bug analysis.

Primitive development team working in the bug tracker without the luxury of a QA team

In QA, too many cooks do not spoil the broth. A large and diverse team is more effective than a small one when trying to keep up with a myriad of software and hardware configurations.
A large teams allows the freedom for members to level up their skills. The more experience on advanced triaging techniques the members have, the less work developers have to spend per bug fix.

There is a long road ahead for KDE to reach a healthy state regarding QA. Recruit contributors early and often. Aim for a feedback loop of recruiting, where even fresh contributors brainstorm to come up with ways to find new people.

I invite everyone to go through these articles and improve them:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging/Identifying_duplicates
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

I also recommend KDE to look into making it easy for QA to perform git bisects for pinpointing regressions. Perhaps this could be achieved by offering compressed repositories containing binary snapshots for every single commit in a project like LibreOffice does.

It’s now much easier to be a bug triager

We’ve just rolled out a significant and welcome policy change to KDE’s Bugzilla bug tracker: Everyone with an account may now edit any bug without prior permission. This means that every KDE Bugzilla user can now be a bug triager anytime they want!

So get out there and triage some bugs! Our documentation can be found here. This is one of the easiest and most impactful ways to contribute to KDE, and it doesn’t require a significant time commitment. Most bugs can be triaged in a minute or two, and boring downtime is a perfect opportunity for some bug triaging! It’s also a great way to ease into development; bug triagers will become familiar with KDE’s codebase and encounter small easy-to-fix issues that are the perfect entry points for submitting patches.

If my efforts seem useful and you’d like to see more of them, consider supporting me on Patreon, LiberaPay, or PayPal.