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.
Adventures in Linux and KDE 
Yeah! Now we’re talking!
LikeLiked by 1 person
Aha, so that’s why I suddenly got bug triaging permissions. 🙂
LikeLiked by 1 person
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?
LikeLike
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.
LikeLike
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.
LikeLike
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). https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging#Set_Bugzilla_fields
LikeLike
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.
LikeLike
The proper way to fix that would be to get rid of CONFIRMED/UNCONFIRMED and just use NEW. 😉
LikeLike
I certainly wouldn’t object to this. We discussed it in https://phabricator.kde.org/T6832, but unfortunately nothing ever came of it. Maybe I should just give it a gentle nudge…
LikeLike
> 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.
LikeLike
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.
LikeLike
Thanks for clarifying this. It would indeed be useful, I think, if you added that information to the wiki. 🙂
LikeLike
Done!
LikeLike
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 https://bugs.kde.org/buglist.cgi?component=general&list_id=1498083&product=kde&resolution=—
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. https://bugs.kde.org/show_bug.cgi?id=390493), and the product list at https://bugs.kde.org/describecomponents.cgi 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.
LikeLike
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 sysadmin@kde.org.
If you’d like to submit a first patch, check out our documentation at https://community.kde.org/Get_Involved/development
LikeLike
Is it planned to replace bugzilla with something that’s user friendly and modern?
LikeLike
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”
LikeLike