Bugs.kde.org improvements

New Contributor Friendliness 2 Minutes

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!

Published by Nate

Published

25 thoughts on “Bugs.kde.org improvements”

  2. Everything that can improve the workflow is exciting, but I hope also KDE will do as GNOME’s recent initiative and try move as much as reasonable possible to a single location/tool (like GitLab). For new users it don’t make much sense that you will have to learn a multitude of (often cumbersome and old) tools that don’t even communicate well with eachother, and it’s both frustrating and wasting everyones resources.
    Not only KDEs fault, but I hope also other software developers/projects will leave ugly things like cgit and sourceforge for good as these ridiculously tools do not make any new contributors to the projects using it. Let’s be honest when things suck instead of making excuses for it. Of course tooling is not the only problem, but it’s a highly important one. It’s not true that people do not want to contribute to open source (often heard!), but the fact is that many projects make it too hard or confusing to get involved. Nobody’s perfect and that’s specially true for open source software development, but that’s no excuse. We got so much that needs to improve if we want to take OS to the next level and secure its future. And that’s one of many reasons why we should be very thankful to have people like you Nate, you do a amazing job. Many a little makes a mickle. Thank you so damn much!

    Liked by 2 people

    Reply

    1. I don’t disagree with you, and it is indeed a pain point that people need to have one account for Bugzilla, and another one for Phabricator, and that the two aren’t linked together very well. I don’t have anything to report on that front though. Switching infrastructure is a major undertaking, and we just adopted Phabricator a few years ago. KDE contributors and developers intermittently express the desire to move to Gitlab, but as far as I’m aware that’s not an option at this point in time. However anything’s possible in the future.

      Liked by 2 people

    2. Nate covered most of it, but I just wanted to mention that right now, KDE has a patch-submission workflow, rather than a fork/branch workflow. Once you get used to Git/Phabricator it actually works pretty well. I do agree it would be nice to have a single, central product to use, but the current workflow is pretty good. You just have to think in the terms of coding on your PC and submitting a patch (as you would with the Linux kernel), rather than creating your own branch and requesting a pull/merge.

      Liked by 2 people

  4. Nice work!

    I’ll take this opportunity to point out the first page for reporting a bug: https://bugs.kde.org/enter_bug.cgi
    This gives a long list of products to choose from before we can start reporting a bug. Can you look into ways to making this less intimidating, perhaps by grouping the products into higher level categories? I have at least 4 categories in mind: Plasma, KDE Applications, Frameworks, Other applications and libraries. This is in order of popularity and what we can expect someone who is here to report a bug report to be looking for.

    Liked by 2 people

    Reply

    1. We just went through and closed all the products that are unmaintained, so believe it or not, the list used to be even longer. It’s not a bad idea, though. Can you (lol) file a bug requesting that? The product is “bugs.kde.org”

      Liked by 2 people

    2. As I spend more time in our Bugzilla, I noticed more situations where products/components are confusing. So, I’ve had it in the back of my mind to propose a cleanup of that, and there has been some previous discussion by others as well. It’s a bit difficult due to the decentralized nature of KDE, but I believe we can make some improvements there. We may be a bit limited due to Bugzilla, but I can look into it.

      Liked by 2 people

    4. Yeah, that’s a good option as well. I’m basically just waiting right now until Bugzilla 6.0 comes out, as it will change the UX a lot.

      Liked by 1 person

  5. Would be nice to have edit option for sent post. You know that sometimes happens we forget add something to our report, and then we need add another message, after sometimes report becomes less readable.

    Liked by 2 people

    Reply

    1. Bugzilla just doesn’t have an edit feature. Phabricator Tasks let you edit description (and it’s much richer markup) but it requires a lot of trust that someone won’t edit bugs badly.

      I’m not sure if KDE plans to move bug reporting into Phabricator.

      @Nate is there any guide to KDE’s Bugzilla-Phabricator split? When I occasionally comment on a Phab task I feel like I’m trespassing on Real Work™ 🙂

      Liked by 1 person

    2. The bug tracker is intended primarily for user-to-developer interaction, while Phab is intended primarily for developer-to-developer interaction. That’s not to say that users can’t comment, and it’s public for a reason. But the feeling you’ve gotten is precisely accurate: it’s where we discuss our work, and any comments made there should contribute to that process.

      This is all more or less documented here: https://community.kde.org/Get_Involved#Getting_in_touch_and_working_together

      Liked by 1 person

  6. Good to have less frustrating statuses, but what about with this: “NEEDSINFO WAITINGFORINFO”
    I reported bug, after got status like above, I updated report adding couple posts. Passed 2 years. Status still the same :-/.
    Of course I’m aware that in case application I reported bug there is very few programmers, so I don’t complain.

    Liked by 1 person

    Reply

  7. Hello Nate, this is my first time commenting here. Thanks for your hard work at KDE. I’m a KDE user, not a programmer, but thanks for communicating about this Bug Tracker improvements with us. I think the new template above is great! Overall, awesome article, please keep your hard work. Thank you!

    Liked by 1 person

    Reply

  8. Awesome you are improving your bugzilla. Frankly, it offers very clunky and old UI. Those improvements help, but the whole buzgilla interface and login should be changed but I realize how big undertaking that would be so I value those small changes.

    The first thing that comes to mind: where are my bugs or where are posts on another topic? It’s there somewhere, I found it once or twice, then I couldn’t find it no matter what. Finding old or existing bugs is also a pain, etc. So UI is just a horror.

    Also, logging and various KDE accounts is a pain and confusion.

    The new statuses raised my resistance at first but on a second thought, they might work although it takes a bit time to get used to it. However, I don’t see “confirmed” status there. Should I assume this hasn’t changed then? It’s a bit weird to have “confirmed” without “unconfirmed” thou… and yet I can’t imagine bugtracker without reassuring and calming “confirmed.

    Liked by 1 person

    Reply

    1. CONFIRMED remains untouched. 🙂

      Once Mozilla upstreams their changes (soon!), we will be working to adopt them and drastically improve the UX.

      Liked by 2 people

Leave a comment

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s