In today’s other blog post, I mentioned how we’ve been getting a huge number of bug reports since the Mega-Release. If you’re not in software engineering, this probably seems like a bad thing. “Oh no, why so many bugs? Didn’t you test your software properly!?”
Since most people are not involved in software engineering, this perspective is common and understandable. So I’d like to shed a light on the assumptions behind it, and talk about the challenges involved in improving software quality, which is a passion of mine.
Don’t kill the messenger
See, bug reports are a “don’t kill the messenger” type of thing. Bugs are there whether they get reported or not, and getting them reported is important so you have a more accurate picture of how your software is actually being used by real people in the real world.
In our KDE world, the alternative to “lots of bug reports” isn’t “few bug reports because there are few bugs” but rather “few bug reports because the software isn’t actually being used much so no one is finding the bugs.” What matters more is the severity of the actionable bug reports.
What bug-free software looks like
That sounds so defeatist! Surely it must actually be possible to have bug-free software, right?
Yes. But to achieve it, you have to test literally every possible thing the software can do to make sure it performs correctly in the environment in which it’s doing it. If the software can do infinite things in infinite environments, then testing also becomes infinite and therefore impossible, so combinations get missed and bugs sneak through. Bug-free software must aggressively limit the scope and variety of those environments to just the ones that can be tested. What does that look like in practice?
- Limit what the software can do in the first place. Remove as many features, options, and settings as possible without compromising the product’s necessary core functionality.
- Limit how the user can modify and extend the software after release. No user-created themes, widgets, scripts–nothing! Every modification to what the software can do or how it looks must go through a the same QA team that QAd the software in its original state. 1st-party modifications only.
- Limit the versions of upstream 3rd-party libraries, dependencies, and kernels that the software is allowed to use. Lock those versions and test everything the software can do on those specific versions.
- Limit how downstream 3rd-party user-facing software (i.e. apps) can interface with the system. Lock it down in a sandbox as much as you can so any misbehavior can’t affect the rest of the system.
- Limit the hardware that the software stack is allowed to run on. Test everything the software can do only on that hardware.
Does this sound very much like how KDE software is developed, distributed, and used? I’d say it’s more like how Apple builds products (and note that Apple products still have bugs, but I digress)! By contrast: KDE develops lots of features and options; we’re liberal with supported library, dependency, and kernel versions; and we don’t prevent you from installing our software on any random device you can get your hands on.
You can see the challenge right away! The foundation of quality is a set of restrictions that we don’t want to impose on ourselves and our users. You folks reading this probably don’t want us to impose them on you, either.
Quality from chaos
So is it just impossible to ensure quality in a permissive environment? No, but it’s harder. That’s right: we in the KDE free software world set for ourselves a fundamentally more difficult task than the big corporations with their billions of dollars of resources. Given this, I think we’ve done a pretty darn impressive job with the Mega-Release. And judging by initial impressions out there, it seems like many others agree too!
So how did we do it?
We lengthened our beta period to 3 months and relied on bug reports from people using the software in their own personal environments.
Yes you, loyal reader! We wanted to hear how our software was working on your 12-year-old Netbook. We wanted to hear how it worked when plugged into two TVs and a rotated monitor, all through a KVM switch. We wanted to hear how it coped with the most bizarre-looking 3rd-party themes. By using our flexible and non-limited software in your diverse ways on your diverse hardware, you’re testing it and finding all the bugs that we lack the resources to find ourselves.
Does this sort of QA work sound like something you don’t want to do? That’s 100% fine. But then you need for someone else to be the QA team for you. There are two options:
- Buy a computer with KDE software pre-installed; there are a lot of them now! Then it’s the vendor’s responsibility to have done adequate QA on their own products. Is it buggy anyway? Complain to them or find a better vendor!
- If you’re going to install it yourself, limit yourself to common hardware, default software settings, and operating systems that are relatively conservative in their update schedules. Then the QA has been provided by others who who already used your exact setup and reported all the bugs affecting it.
Become a superhero
But what if you do want to help out with making the software better for others, but you’re not a programmer? Congratulations, you’re a real-life superhero.
We’ve already talked about reporting bugs. It’s also important to do a good job with your bug reports so they’re actionable! I’ll encourage folks to read through our documentation about this. Low-quality bug reports don’t just waste our time, they waste yours as well!
But where do all those 150-200 bug reports per day that I mentioned actually go? There’s a flip side which is that someone needs to do something with every single one of them. The more bug reports we get (which, again, is good!) the more we need people to help triaging them.
Because the truth is, most bug reports don’t begin life being actionable for developers. They may be missing key information; they may be mistaking a feature for a bug; they may be describing an issue in someone else’s software; they may be about an issue that was already fixed in a version of the software that the reporter doesn’t have; they may be describing a real issue but in an unclear and confusing way; and so on.
The job of bug triagers is to make each of these bug reports actionable. Ask for missing information! Move them to the right products! Set the version and severity appropriately! Mark already reported bugs as duplicates of the existing report! Mark obvious upstream or downstream issues accordingly and direct people to the places where they can report the bugs to the responsible developers! Try to reproduce the issue yourself and mark it as confirmed if you can! And so on. It isn’t terribly glamorous work, so there aren’t very many people lining up to be volunteer bug triagers, unlike developers. But it’s very important. And so every person who helps out adds resources to what’s currently a very small team, making a massive difference in the process.
If you’ve been looking for a way to help out KDE in a way that doesn’t require programming or a consistent time commitment, this is it. Triage a few bugs here, a few bugs there. Chip in when you can. If 30 people each triaged three bugs a day (this would take under 10 minutes, on average), we’d be in an amazing position.
So get started today! I’m available to help in the #kde-bugs Matrix room.
Still don’t wanna? Donate to KDE e.V. so we can eventually hire our own professional bug triage and QA team!
Adventures in Linux and KDE 
Yeah, this is so true!
Also, as I personally am on the receiving end of bug reports, I can 100% say that people often mistreat a bug for feature. A checkbox here and there makes functionality go 180 degrees which they did no even consult how software is supposed to work even in cases when the action is somewhat self-explanatory.
Normies, if they have not interfaced with IT world, they do not even know how to properly make a bug report, they have never seen a git issues, bugzilla or jira. They don’t want, understandably (they are business users, they know nothing about inner workings of sofware), to deep dive in the software, therefore bug reports may end up like “I click there and nothing works”, without anything else, this is very unproductive and must be followed multiple times to get the setup, conditions, versions, intent, etc. to get to the level of actionable bug reports. Sometimes it is hard to describe the issue for a techie, especially for the random seemingly out-of-the-blue type of issues.
I think actionable bug reports will always be an uphill battle, we can try to improve the situation, but the more normies use the software, the harder it will be to get good bug reports. There are lazy non-normies too, that doesn’t help either 🙂
LikeLiked by 1 person
Spoken like someone who knows what he’s doing and feels my pain 🙂
Ultimately I think as we get more less-technical users, we need some kind of barrier between them and the bug tracker, because a greater proportion of the issues they’re facing are going to be caused by their own inexperience or accidental damage, rather than actually being real bugs. My hope is that the KDE forum at https://discuss.kde.org can server as a sort of “first line of defense” where tech support can be provided to these people and not-a-bug problems can be filtered out.
This can even be beneficial for them too, since a bug tracker is more likely to bring you in contact with grumpy engineers who don’t have much of a “customer service” attitude, and normies often react quite badly in such interactions.
LikeLiked by 1 person
Nate, I didn’t even know that this discuss forum even exists! Why didn’t I know about this? This is wonderful. Sometimes I have a problem, but before submitting any bug, I need to gather information, if this is normal, or not, or are others experiencing it, is there a solution and so on.
I do submit bugs from time to time, but a forum focused on KDE/Plasma is still a good place to start.
LikeLiked by 1 person
«the more normies use the software, the harder it will be to get good bug reports»
Rught, but on the other, many “normies” know better about “real life” usage than you, because they use their computer for real work: a professional office worker with no coding knowledge at all may know better than you about bugs with office applications and scenarios; he spends 7 hours a day involved in such tasks and devs spend… 7 a month? And a retired granny may know better that she losses sound for the whole session after playing certain family videos.
Also, professionals or enthusiast aficionados may probaby know better what to expect from the software. I mean that a photographer, photo retoucher, etc, probably knows other programs besides Digikam, Showfoto and Gwenview, and not only in the Linux echosystem, so it’s probable that he can suggest lacking features, better implementation of existing ones, as has seen on, say, Darktable, Capture One, etc, or point to crashes that happen in scenarios that probably developers have never seen because devs have never pushed their products there*.
I’m aware that you need to filter the wheat from the chaf in some manner or your job would become an unmanageable hell, but I’m not convinced of disregarding common and professional users at the stroke of a pen without further consideration just because they probably aren’t going to write useful reports (BTW, implement some autotranslation AI in BKO and let users report in their native languages, I think you’d get more and better redacted reports if people doesnt need to struggle to write in technical english).
Besides, let’s not forget that normies are much more in number and 500 eyes _often_ see better than 10, even if these 10 have special “superpowering” glasses.
So, summarizing, you are right, but it should be considered also the reality that just taking geeks into account will probably lead to miss many of the every day bugs that make “the Linux desktop year” never come (it’s not the developers who has to adopt Linux desktops to make the clucked Linux desktop year come but the normies with their normal every day bugs). If you admit only Geek’s voice you’ll probably end making a desktop for geeks.
* Let me illustrate with this example:
Have you devs ever needed to check several folders with lots of PDFs, ODTs and Epubs without clearly descriptive file names, so you have had to show the colums, Title, Author and nr. of pages in order to classify and tag them correctly, thus you have used Dolphin split view, but, damn!, there’s no horizontal split option, and vertical split cuts the horizontal space by 50% and cponsecuently you cant see all that crucial info for you task?
My guess is that no, you never were in such a situation and that’s the reason you never implemented (recovered from Konkeror’s ol’ good times, in fact) this feature. And that’s normal, you are developers not archivers, literature teachers nor any other jow that involves managing hundreds of books and documents every year
LikeLike
Your example isn’t a bug, but rather the lack of a feature. Nonetheless, it does make sense!
Normies definitely know about real life and have real issues. What they generally lack is the ability to report their issues in an actionable way: they’ll describe the impact to themselves and ask for workarounds; uninstall the software and destroy the environment in which the bug occurs; and struggle to provide technical information when asked specifically.
I’m not suggesting that their concerns or reports should be ignored; I’m explaining the difficulty for both parties in exposing normal people to a bug tracker. Ultimately I think a better solution is to use customer service/helpdesk personnel to filter reports and provide support for people just looking for workarounds, and then report the issues themselves using technical language.
This is kind of what discuss.kde.org does already, and I hope to see it become even more useful for this purpose!
LikeLike
Yeap. How many developers are working on Plasma on average? A few hundreds? Maybe a few thousands at most. While there are hundreds of thousands (probably a lot more) users with different hardware, different setups, own customizations, and so on.
I switched to Plasma 6 and although there are some bugs, there are no showstoppers and in overall this is a very good release, especially if one considers how many changes were done under the hood.
The only things I am a bit disappointed is the lack of the migration software. After update and the reboot, there should be some mandatory window with scripts/options to migrate Plasma 5 confs into Plasma 6, check potential conflicts, propose some general solutions (like uninstalling packages, deleting or renaming the file/package/folder, etc.). In fact, this should happen on pre-sddm screen, because on Manjaro this was the first major error, but in that case it was the fault of Manjaro. Plasma 6 was available for a long time, and there was enough time to test it and adjust it. Unfortunately, Manjaro didn’t do that (although they knew it has to be done two weeks prior the release) and during update, Plasma defaulted to distro default SDDM theme, which wasn’t upgraded, so it was incompatible, so we were greeted by the fallback SDDM with virtual keyboard… Not a good first impression. Then there were my old configs and additional files that were conflicting with Plasma 6 causing all kinds of various bugs. I had to rename .config and restore app configs minus the Plasma related configs to fix them.
People were running Plasma for years and all kind of modifications were possible, because Plasma allows for that. Sadly, developers mostly work on vanilla, clear environment, which makes them forget that this is in fact atypical environment for many users.
Luckily, I got used to Plasma fixing initial bugs very quickly. A few releases, up to 6.0.4 and most annoying bugs will be fixed, so all is good.
Again, for a such big release, this in incredibly smooth experience. I was one of the unstable testers on Manjaro, so such issues are part of that territory. Stable users will get everything fixed or maybe even 6.0.1 or later version,
As to my biggest issues: sound themes are not customizable as it was before, so I can’t add startup sound, which is weird. If it is possible, it’s masterfully hidden… Overview is wonderful, but suffers from the same lag when more than 4 windows are opened. Latte doesn’t work anymore, which was to be expected. So, nothing too serious. I also see some other, smaller bugs, which I’m sure will be gone with time.
LikeLike
The number of people who have ever contributed to Plasma is definitely in the hundreds, maybe the thousands. But the number of current active contributors is less than 50. The number of daily regular contributors is, like, 8 people. Maybe 10 or 12.
Check out https://invent.kde.org/plasma/plasma-workspace/-/graphs/master?ref_type=heads if you’d like to get a sense of how many people are regularly actively working on Plasma (note that this is not perfectly representative since that’s just the plasma-workspace repo, but it’s a big active one, so it’s not the worst thing to look at).
The startup sound is broken again; it’s just a bug: https://bugs.kde.org/show_bug.cgi?id=482716
The issues with people who had incompatible 3rd-party content is real. I see this as mostly a messaging problem. We’d been announcing for years that major releases can and will break compatibility, but I think the problem is that we didn’t have a way to tell users on their own systems. I’d like to improve on that in the future.
LikeLiked by 1 person
I had used Nvidia hybrid laptop and in hybrid session that used Intel for most graphics (Nvidia on demand) all worked fine. However, currently I’m on laptop with AMD CPU and AMD GPU, also on hybrid setup, so most graphics is handled by Ryzen 7 7840HS, and whenever I use multimonitors, I get various visual glitches, like blurred areas covering texts, blurry areas following cursor, etc. So AMD is not so bug free as one might think. In fact, I have more hardware issues now with AMD as I had with Nvidia… Hopefully it will be resolved with time. Wayland was and is gold thou, both on AMD and on Nvidia (on my old laptop).
LikeLiked by 1 person
Fixing bugs is an endless journey, and the community can’t thank you enough for all your efforts.
On that note, I’m curious if NVIDIA GPUs aren’t used by the KDE devs at all? On Plasma 6 with NVIDIA, the desktop is riddled with visual glitches to the point that it is not usable, and making Wayland default would be a mistake.
LikeLike
Most of us don’t, indeed.
The thing is that there’s only so much we can actually do to work around NVIDIA’s own driver bugs. Many or even most just need to be fixed by them. To a great extent all that’s going on here is that we’re actually using the features that the driver says it supports, and then they don’t work properly. This is generally fine with Intel and AMD (especially Intel) but the NVIDIA driver is just constantly plagued by these issues.
I think it’s telling that Valve opted to put an AMD GPU in the Steam Deck.
Obviously it’s cold comfort if you happen to have an NVIDIA GPU, or even worse, a laptop with one built in. But honestly… get rid of it and buy one with Intel or AMD hardware. It just works better, and this isn’t a new thing, either.
LikeLike
Nate. LOL, lately, almost every release broke the startup sound. This should be on main “to do list” when checking the beta release. I get that probably developers didn’t use that feature, but users do.
However, I am curious, if there is some sound settings panel? Previously, sounds were independent and set in notification settings, which was very hidden not intuitive. Now that sounds are grouped, this means we can’t choose sound from one theme for action B, and then sound from the second theme for action A. However, there still should be a setting to turn off/on particular sounds, if one don’t want them. I like startup sound, but I get if someone will prefer not to have it. So there should be toggles for sounds on each theme. This isn’t as flexible as it was before, but I guess it would be acceptable, at least for me ;).
As to so little people working actively on Plasma… this is scary. There should be more, a lot more. This is amazing that Plasma is so well maintained nowadays and so little buggy, given the complexity and all the options.
The transition SDDM screen would be a nice idea for such big releases, where backward compatibility gets broken. I guess it is too late now and users need to solve it on their own. Maybe a global = “reset all settings to defaults” would be useful? Or “save all settings to a file”?
Then it would be easy to save current settings, just in case (instead of tracking down config files), try defaults and load the settings from one file?
This would help debug user caused issues. Instead of asking to check out scattered, chaotic and confusing configs, there would be just copy-paste instruction: to backup current settings to a file, reset to defaults, relog the session (or reboot), try out if the issue exists, if it still does, restore settings from the file, relog the session.
In massive releases in the future, you could just show up pop-up screen with such instruction.
Just a thought ;).
LikeLike
System76 currently has 7 people working on CosmicOS and the original Android team was also just about 20 according to this recent Tech Over Tea interview (link with timestamp). So don’t be afraid of low numbers, a lot of stuff can get done by a focused and effective team with a clear vision.
Well, I mean sometimes I wonder how people pull it off because it takes me months to improve only a small aspect of the whole thing, and Plasma’s scope is wide, and the surrounding ecosystem of other KDE software is even bigger. So I have enormous respect of people that get a lot done in the little time that’s available. But it does come together in the end.
And the flipside is also true: every single contributor can leave a lasting positive impact. As someone with enough time on my hands, I hold the power to tilt the scales of the Linux desktop ecosystem in one direction or another. Together with a handful of other people, of course. And because it only takes a few dedicated contributors to really make a difference, the whole “please donate so we can do much better” message is really as true and important as KDE promo people make it out to be.
LikeLike
This sounds like a statement that would come from a GNOME developer 😂
LikeLike
I think it’s the opposite, no? GNOME does impose those restrictions on itself and its users, in the interest of achieving greater stability. KDE does not; it’s one of the major points of differentiation between GNOME and KDE.
LikeLike
Really, if there is no QA, it is necessary for you to test yourself, there is no excuse, you are making software that many will use and because of these basic things like testing things well, they make domestic and not so technical users abandon Linux, gentlemen, you have to improve.
LikeLike
There is lots of QA. It comes from internal developers as well as people using the beta releases, who are volunteering to perform QA tasks–same as the developers who show up to volunteer to write software.
LikeLike
Let’s go, it’s possible! I use kde every day, let’s all make an effort to improve the quality of the releases in the versions. Thank you
LikeLike
I’m a user who uses Cinnamon as my main desktop but relies on a lot of KDE apps. I feel like most of the bugs I encounter are “Dark mode doesn’t work when using App X in a GTK desktop environment.” In most cases I can replicate the exact same theming issue on my Mint system as in a fresh Gnome Debian VMWhen reporting, I often feel unsure as to what exactly to include. Cinnamon’s bug report form asks for the content of the .xsession-errors log file: Are those relevant to a theming bug on a KDE app, even if the issue isn’t Cinnamon-specific?
In the past, I have also had theming issues with Gnome apps on non-Gnome GTK desktops, and the Gnome developers took the approach of saying “anything that happens on a non-Gnome desktop is not our problem.” I’m really grateful that the KDE devs actually consider fixing things for non-Plasma users (even though we’re obviously less of a priority for you.)
LikeLike
xsession errors are not relevant in this case, no. For an explanation of the cause of the theming issues, see https://community.kde.org/Get_Involved/Design/Frequently_Discussed_Topics#Theming/color_issues_when_running_KDE_or_Qt_apps_in_non-Plasma_desktop_environments.
LikeLike
How can I report usability issues? I tried to connect my Office 365 mail account (not @outlook.com) and the thing that bugged me the most is: the whole thing is working! I just have to manually add an Akonadi Exchange resource, disable Password authentication, enable OAuth2, and disable auto discovery, to get me to the page where I can log in.
I had to disable 3 default options and press a button to get a login prompt for a kind of account (Office 365, @whatever.onmicrosoft.com) that’s quite COMMON! And no, the wizard didn’t help me at all (it sent me to IMAP while Akonadi CAN do the whole Exchange thing)
Please, guys, you can do better.
LikeLike
How the Wayland gestures in Plasma 6 work? Currently, when I do “4-finger up swipe”, it activates the overview effect. After the overview is fully triggered, “4-finger down swipe” have opposite animation, suggesting it will close the overview and focus the last focused window. However, it JUMPS to the next virtual screen EVERY TIME.
Is this intentional? If so, what would be the usage of such behavior. It’s incredibly frustrating. Or maybe it is a bug and should report it (if not reported already)?
Frankly, this is so consistent behavior, that this is hard to miss, so probably it was already reported.
Sometimes, there is JUMP-BACK to the first virtual screen, but it doesn’t always happen, so I am confused about the rules and reasons of such behavior.
LikeLike
What you’re experiencing isn’t intentional. I can’t reproduce it myself. It’s possible your touchpad is broken such that a four-finger downward swipe is also interpreted as a four-finger left or right swipe, which would trigger the system to switch to the next or previous virtual desktop.
LikeLike
Nate, is there a way to look out the touchpad input to test if this suspicion is true? Maybe there are ways to disable/fix it in software? But first, I need some output to confirm it and possibly submit the bug somewhere, not sure where yet. This happens only with 4-fingers down, so this doesn’t feel like intended.
Probably, I will have to test it on other user or different distro to rule out the possibility of some config issue.
Thanks for the confirmation that the gestures are not behaving like this intentionally and that it isn’t how it happens for others.
LikeLike
I’m not sure, sorry. There are some libinput event monitoring tools you could use, but I’m not sure how to interpret the output.
LikeLike
Is it possible a check software to verify the operating system the single user runs before the upgrade installs the new system packages in order to adapt the previous setup to the new instances requested to make usable the new DE, so to avoid severe issues?
LikeLike
And there are also those “divisions” of bug reporters that get discouraged and abandon because they see how dozens of the bugs they reported since more than a decade ago, never got fixed despite developers admitted they were valid and useful.
There are few sentences as irritating as «It’a a well known bug». ¡F*ck if ye know it so well stop fixing emoji-ish silly crap and fix this 13 y. o. bug which affects real functionality! xD
Ok, ok, I’m ranting a bit. I know that if KDE had a lot of money to hire 100 programmers 35-40 working hours a week things would be very very different, and you do all you human forces and free time permit and we love you for that :). But you need to admit that many good bug reporters are lost every year because of their dismotivation after feeling that they report just for nothing.
LikeLike
Demotivation is real, but it’s also kind of a lousy excuse to avoid reporting issues. Yes, not every bug that gets reported is fixed, but every bug that’s not reported only gets fixed after a developer experiences it.
All good things in life require effort. Otherwise, we’d all be slim, muscular, speak multiple languages, have advanced degrees, and run successful businesses. And bug reporting is easy in comparison. It takes just a few minutes.
Really bad issues don’t tend to stick around for years unless they’re exceptionally hard to fix. The ones that linger are generally the ones that are barely bugs, at best minor irritations–or require a very specific combination of hardware and settings to experience. Frankly, in a resource-constrained environment, it’s appropriate that these aren’t prioritized. If they were, the big important bugs would get fixed more slowly and features necessary to maintain or increase competitiveness wouldn’t get implemented, causing the entire product’s popularity to wane over time as it lost relevance.
LikeLiked by 1 person
«not every bug that gets reported is fixed, but every bug that’s not reported only gets fixed after a developer experiences it»
Obviously, but take into account that most of KDE users are not native English speakers. So, no, excuse me, but redacting a report which is clear, explanatory and useful does not take just a few minutes. One has to think how to express the problem, then rethink; then, translate, check for errors, consult some dictionary or web translator -but not too much since they f*ck things up often-; then, re-read to verify there aren’t many incongruences or mistakes as far as we can since we aren’t natives; and still there will be some mistakes. Then, some days later, some developer will probably reply asking for some more info, and the process will restart.
That paragraph above has taken me about 15 minutes. It has barely 10 or 11 lines and I haven’t needed to explain complex or ambiguous things, and sure there’s a lot mistakes in it. So, don’t be so optimistic about the easiness of bug reporting for most of KDE users, that’s supremacism. Try to write a bug report in spanish or german or wathever foreign language you studied at school and you’ll see.
Perhaps most bug reporters are very fluent in english; specifically, technical english, not common english nor literary english nor, of course, “simple tourist english”. If that’s the case, it just means that only fluent speakers dare to report, and that’s not good news since it doesn’t augur an easy increase of reports.
I dont blame KDE’s people for not being polyglot. Life is short and if we all had to learn fluently a lot of languages we could not learn almost anything else, at least in depth; we would be “stupids in five languages” -philosopher Ortega y Gasset dixit once about some intellectual-, but since BKO can’t translate -automatic translations aren’t too trustable either, but AI is improving them, it seems-, at least be understanding and dont accuse tired bug reporters of using “lousy” excuses. For many of us it takes a lot more than you think to write -and respond- bug reports.
The funny side is when the developer that answers to your report writes and reads english even worse than you and the conversation starts to seem like a dialog among drunkards xDD. Unfortunately this may end in demotivation on the dev’s side 😞
But all that’s not the main problem. Most of us, KDE real lovers, are willing to do such efforts, we even take the time to take screencasts/shots to make sure our bug reports are as clear and unambiguous as possible. The problem comes when months pass and no further reply is received -except for occasional warnings about duplicate bugs- or the infamous “It’s a well known bug. Keep dreaming” comes to scene, or the “there’s a chronical lack of manpower”. Those kill any hope to get the bug solved and the will to keep reporting, even if they are true.
BTW, when saying “bug report” I mean feature requests too. For example, I -and other users before me- requested Dolphin horizontal split more than a decade ago, Dolphin history -this finally was implemented few years ago-, Nextcloud Notes support for Kjots, configurable -really, not only options: 1. Huge, 2. Use a magnifier glass- icon size for the systray, numerous bugs and deficiencies affecting Akonadi apps, Panel, and some other crucial componente of the KDE environment that never got implemented of fixed. Surely none of them were vital issues, the planet will keep spinning if they are never implemented/solved and Plasma is still functional, but most of them are clearly “features necessary to maintain or increase competitiveness”, admitted by you, developers in some of your answers and in IRC and Telegram chats.
And this is not a matter of ego, I’m talking about my case because it’s the only I can speak with full knowledge of the facts, but have read even better bug reports/requests by other people that I think should be prioritary: predictive text and grammar check in Kmail and Calligra, bearable “read aloud” infrastructure for blind users, making Baloo usable for real work, etc. Not features I need a lot, but I think they are, in 2024, fundamental “to maintain or increase competitiveness”. Most of them are features that smartphones include since 10 years ago!
And I finish my long answer -BTW, more than 1:20 hours, Nate. Again, I dare you to write an explanatory text like this, thrice as short, in your second language, trying to do your best; test if you are able to do it in 4 or 5 minutes…- saying that I’m aware that the main reason for all those issues not being solved is the lack of manpower. I’m not going to say that it’s a “lousy excuse” to not solving them. No, I know it’s true. That KDE should get lots of financing to be able to hire at least a couple of dozen full time extra developers to complete all those pending bugs and requests -when really interesting and useful, sure-; and maybe a couple of dozens were few, but, anyway, the same way I think most of the users believe you, devs should not believe ex-reporters are “lousily” using excuses. We have really lost our motivation and seen how our absence doesn’t make KDE’s development slower nor faster.
BTW, those 100.000 $ Calligra got few years ago, but Calligra’s development stalled for ever didn’t smell nice either…
Cheers and thanks for your time.
LikeLike
J’ai decidé de faire ce que tu as demandé et ecriver ma reponse en utilisant une langue pas maternelle, ou je ne peux pas parler courrament. C’est en effect difficile! Donc je comprends ton point de vue. Mais à l’autre côte, aujourd’hui on peut traduire à la machine es ces traductions sont vraiment tres bonnes. Ca facilite la tâche un peu, au moins.
OK, back to English before the cobwebs of my high school French completely bury me! Ultimately I think I’m just going to repeat my point: yes, there are challenges, but nothing good in life is easy. And if you don’t want to contribute via bug report because you don’t feel your English is good enough, or don’t want to sign up for another account, or have difficulty navigating Bugzilla, that’s okay too–use discuss.kde.org to report the issue and then the more technical people there will determine if it’s really a bug or not. There are even language-specific forums you can use.
Edit: I was able to write the French text in 6 minutes.
LikeLike
Two of my devices on KDE Neon recently updated to KDE6. One of them perfectly, the other one not. No sound, even after a fresh install. Is there a bug report on this already?
LikeLike
Not to my knowledge. Sounds like maybe a package got uninstalled, perhaps plasma-pa?
Regardless, the right place to report or discuss issues of this type is https://discuss.kde.org
LikeLike