15-Minute Bug Initiative update

A tad over two years ago, I revealed the 15-Minute Bug Initiative–an attempt to improve the out-of-the box user experience for Plasma by focusing on fixing obvious papercut issues. The idea was to crush the meme of “KDE is buggy” the same way we systematically addressed similar complaints like “KDE is ugly” and “KDE is bloated” in years past.

Well, it’s been two years, so how did it go? Let’s talk about it! First some numbers, because we like numbers:

  • Starting number of bugs: 92
  • Current number of bugs: 32
  • Total number of bugs fixed (because more were added over time): 231
  • Percent of all total 15-minute bugs that have been fixed: 87.8%

(note if you’re from the future: if you visit those links, some numbers may be different–hopefully lower for the second one and higher for the third one!)

Wow! That’s quite a few. So this initiative looks like it’s been a real success so far! Nevertheless, 32 bug reports remain open, so we can’t declare victory yet. These are some of the stubbornest, hardest-to-fix bugs that require major re-architecting, working upstream, or similarly challenging efforts. Hopefully the pace of improvement seen over these years has managed to convince you that they’ll eventually be resolved as well.

“Wait a minute, Plasma is still buggy AF you n00b”

Keep in mind these aren’t all the bug reports in the world we can fix (there are over 5000 of them for Plasma and Plasma-aligned software alone), just the ones I and some others have deemed to be most obvious to the average user! If you’re not an average user because you have three monitors arranged in a weird shape, each plugged into a different GPU from a different vendor and its own different DPI, scale factors, and custom Plasma panels, plus 4 activities and 9 virtual desktops and 6 internal disks, only half of which automount, and 12 apps set to autostart, and each of them is installed onto different disks, 15 window rules, and finally a custom theming setup including Kvantum themes and Aurorae window decorations… then yeah, you’re probably going to experience some more bugs compared to a more typical user who doesn’t have such a complex setup!

That’s okay. We care about you too, and we do work on those kinds of more esoteric bugs because many of us also have complex setups! But progress here will be necessarily slower, because the complex setups are more varied, more unusual, and harder to debug. And let’s be honest here: those of us with setups like these are experts capable of working around most bugs we find, who really should be helping to investigate and fix them. Admit it, you know it’s true!

But in a way, this is good: it represents Plasma moving from “It’s generally buggy” to “it’s specifically buggy–buggy with only certain less common combinations of settings, rather than buggy in a way that anyone can find within 15 minutes of using a system with its default settings. Improving on that was the point of this initiative.

Next steps

Up until now we’ve been ignoring Wayland-only bugs here, because the Wayland session was not the default one. Well, with Plasma 6 that changes, so all of those Wayland-only issues that meet the loose criteria to be a 15-minute bug will be promoted. Similarly, current 15-minute bugs that are X11-only will be demoted. So sometime in the next few weeks, expect the list to shift around a bit.

Once the number gets down to 0, it will of course go up again periodically as new bugs are found or introduced. But this is great! It means we can whack them as they appear, rather than letting them pile up over time. In this way the list becomes a “rapid response needed” task list rather than a backlog we’re always behind on.

What happens with those development resources once the 15-minute Plasma bugs are under control? I have a plan, first articulated in the original announcement 2 years ago: extend the program to Frameworks bugs! There are quite a few candidates there too. And because frameworks bugs can affect Plasma and our vast app library, quality will go up overall.

Speaking of those apps, once the 15-minute Frameworks bugs are also down to zero or close to it, we can include app bugs. This will finally give us complete coverage! I have a dream that one day, we’ll have a stable and mostly bug-free UI layer and our limited development resources can be focused more on performance work, sustainably-crafted new features, usability, more standardized styling, etc. I think it’s doubtful we can get there while we’re still battling routine bugs all the time.

How you can help

As always, help work on the existing 15-minute bugs if you can! If not, it’s always useful to work on bug triaging, so that more of those issues that will eventually become 15-minute bugs can get discovered. Another impactful way is to donate to KDE e.V., the nonprofit that support KDE on a ridiculously small budget. We’re still running the Plasma 6 fundraiser which represents a great way to donate!

7 thoughts on “15-Minute Bug Initiative update

  1. An increasing number of reported bugs is actually a good sign that more users are using and attracted to KDE Plasma, so the project is alive, and has a solid base of testers. The dangerous thing in the development of any software is when you see a shrinking or fixed number of bugs over a period of time, this mainly reflects a bad quality or insufficient number of testers which reflects a shrinking number of end users.

    KDE Plasma is mainly used by users who love to tweak their desktops and have more control over its customization, that’s the main reason it is currently the most popular among Arch based distros users. This way of usage will always generate more complex and different bugs.

    What we love about KDE Plasma is that the team never chose the easy/coward way to tackle the high number of bugs by removing/limiting features and locking the desktop customization like how some desktops did it.

    Liked by 2 people

  2. Great to read the progress ! Plasma 6 is becoming not just ‘a great update to the next version ‘ but also a great update in the way the project tackles various challenges. Hats off to all, keeping my fingers crossed and very happy to have become one of the supporters. Keep on rocking, kr Mark

    Like

  3. Hi!

    While I share the sentiment about great progress Plasma did over these years, there’s a big flaw that was introduced some time ago which went under my radar ’cause I used to use Global menu applet on a top Plasma panel. The nature of the issue is not all KDE (Plasma etc) apps react to Ctrl+M shortcut to show a classic menu bar, which is a must especially when there’s no hamburger menu available in such app at all, e.g. KDE Partition Manager, or Qt apps outside KDE umbrella and others (Cantata, Octopi, virt-manager, you name it). Once I removed the top panel with Global menu applet, the menu has gone, and the only option I left with was adding a menu button to window decorations, which is, honestly, such a pain to use — compared to a classic menu bar. IMHO what you guys need to implement is showing menu bar by default for apps that don’t have a hamburger menu, plus an easy and reliable way to toggle menu bar in exchange to hamburger — could be a an extra option in a context menu of the latter.

    This flaw is HUGE, effectively restricting infinite amount of apps to their very basic functionality.

    I am not sure about fresh installations though, they might be OK and behave correctly, but somehow I am not certain that it is 100% true.

    Like

    1. Just so you know, because I’ve experienced disappearing menu bars as well, you can fix the problem by editing the config file for the KDE app in question. (I had to do this to get my menu bar back in Ark and a couple others). I wish I could remember the name of the INI key that flips this config option, because it seems some actions cause it to get set for e.g. the global menu, and then you don’t have an easy way to change back. I agree that it’s a big problem, because KDE’s philosophy is not at all consistent with editing text files to change UI configuration.

      Maybe somebody else knows what the INI key is, or maybe you can find it in one of your RCs. Should be a simple grep on your ~/.config to get your applications fixed. It’s a workaround, but it should work.

      Liked by 1 person

Leave a comment