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:

  1. They work on something meaningful
  2. They get familiar with the structure of the project
  3. 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

  1. Knowing who the subject-matter experts are
  2. Discovering weak points in the organisation
  3. 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:

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.