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.

17 thoughts on “It’s now much easier to be a bug triager

  1. Thanks, this is a great improvement! I remember when i tried to report something to a wishlist a while ago, but was unable to tag it correctly because I lacked some special permissions… XD

    Perhaps on to translation next? That potential translators are currently expected to be familiar with maillists, need to read a wall-of-text about the custom tools used and need to contract someone to jump onboard seems all unnecessary, specially since most translation projects do not have such high level requirements. Maybe KDE could do as the elementary people and set up a Weblate server to ease the entrance?


    1. Yep, the other New Contributor options also need some love. Translation is one I’ll have a hard time helping out with, since I’m not able to any myself, not being fluent in any non-English languages.


  2. The only effect is that people set bugs to CONFIRMED in the hope they get fixed faster. We really need to get rid of this myth. Developers are less likely to check bugs with CONFIRMED, because they believe someone else already investigated.


    1. As a new bug triager, I must admit that the Confirmed status is a bit confusing. I’m wary of being the one to set this tag on a bug. Could this be made clearer in the wiki, please? The current description says “Set the bug status to CONFIRMED if you can confirm it”, which could be intrerpreted as “I reported it and it happens to me, so it’s confirmed” (which I guess is not what we want).


    2. Actually, it’s the opposite. KDE has been using the CONFIRMED status wrong for years; nobody else does it this way. Confirmed means just what it says it means: “the bug has been confirmed to exist, so work can start on it”. We shouldn’t be overloading it to mean “work has started”. If that is a valuable status, we should get it formally added to list of options. If anyone is under the mistaken impression that it means “someone else is taking care of this”, that’s what the Assignee field is for.


  3. > I reported it and it happens to me, so it’s confirmed

    Using this interpretation, every bug is confirmed when reported. I doubt a report would report a bug that he does not see on his system.

    The correct interpretation is when a bug triager or developer confirms that the issue the reporter sees is indeed caused by component where the bug is assigned.


    1. Right. And that’s exactly what the wiki page says right now: it tells the bug triager to maek it as confirmed if he can reproduce the bug as described. If you’d like I can make this more explicit, and add that it should only be marked as confirmed if the component is also correct, and also mention on the Bug Reporting pages that users must not mark their own bugs as confirmed.


    2. Thanks for clarifying this. It would indeed be useful, I think, if you added that information to the wiki. 🙂


  4. Confirmed as “this bug really does happen” is intuitive for me. I recall that some bug trackers (e.g. Canonical’s launchpad) will automatically mark bugs as confirmed if more than one person reports that it is affecting them.

    I resolved somewhere around 25 bugs at—

    It was a mix of closing years old KDE 4 bugs as Unmaintained and moving a few into relevant products.

    Going to try to circle back to this general area periodically. But it seems like DrKonqi is not registering the right product (e.g., and the product list at is far too large and full of Unmaintained / Deprecated entries to ask people to file their bugs against specific products. So I’d like to help out with better automation and overall process.

    Also hoping to do a first bug fix at some point. Starting to build stuff from source, but it’ll be slow going. I’m still mostly on macOS and running Linux in Virtualbox for now, while occasionally dusting off my old Linux laptops.


    1. Thanks so much for your contributions! I agree that there are a lot of products that we need to scrub and close. We’re actually planning to to a mass close on the plasma4 product about a month after Kubuntu 18.04 comes out. There are other similar things e.g. triaging things in kio and moving them to frameworks-kio if necessary, then closing kio.

      If you want to help out with the excessive number of products, that would be much appreciated, and I’d recommend starting an email thread on

      If you’d like to submit a first patch, check out our documentation at


    2. No, we’re staying with Bugzilla. Oftentimes “user-friendly and modern” means “so easy to file a ticket that there’s a neverending flood of garbage” and “limited or nonexistent tools for categorization, organization, status tracking, and searching”


Leave a comment

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

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

Facebook photo

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

Connecting to %s