A typical day in bugs.kde.org


I’m sorry that $feature behaves differently to how you expect it. But it’s the way it is and that’s by design. The feature work exactly as it’s supposed to work. I’m sorry, this won’t be changed.


With decisions like that, no wonder KDE is still a broken mess.

I wonder why the hell I even bother reporting issues. Bugs are by design these days.

Never again.

Have a nice life.

66 Replies to “A typical day in bugs.kde.org”

  1. I have had exponentially better luck reporting bugs to KDE than to Apple… My Siri and iBooks bug reports may be approaching their 4th anniversary without even an acknowledgment. *That* is “never again”.

  2. If that is a typical day, then perhaps there’s an overall message you’re all missing: KDE’s design decisions are incongruent with the users’ needs and desires.

    1. Every bug tracker of a popular project is full of people with this kind of attitude, doesn’t matter how good a job you’re doing.

    2. You can demand when you hire a programmer or when you are an owner of commercial product and you have guaranteed support.

      KDE is open-source. If you need something different that what hackers doing in want to have, make your own fork and code everything your way.

    3. That’s a fallacy that I can turn on its head and say: users who agree with the design don’t report bugs. Therefore, comparing the number of such bug reporters with the total number of KDE software users, KDE’s design decisions are _overwhelmingly_ congruent with the user’s needs and desires.

      Neither conclusions are warranted, of course.

    4. > If that is a typical day, then perhaps there’s an overall message you’re all missing: KDE’s design decisions are incongruent with the users’ needs and desires.

      If KDE doesn’t satisfy its users’ needs it wouldn’t exist. There are just some users that eventually need to understand that KDE’s ones are not the products they are looking for and that they need to try something else. Some of these users don’t know how to say that in a respectful way.

      1. What do you have to say of users of KDE 1, 2, 3, and 4 who find KDE5 unsuitable? Did the users all change their opinion, or did the project take a turn in the wrong direction? I’m inclined to say it is the latter because I know personally it is not the former in my case. It a bit funny that KDE use to offer a lot of choice, but now the only choices offered are take (no thanks) or leave it (done). I would be happy to use KDE4 forever, but even that choice is being limited by KDE devs screaming about KDE4 being unmaintained and suggesting distros drop it in favor of unfinished KDE5. You say thre is a choice to fork but scream at people who dare to use much less try to maintain the working codebase. Fortunately, despite your protestations, KDE4 has been forked, hundreds of times in different distros and personal repos, so it is in fact maintained and will continue to work. KDE5 on the other hand continues to damage the KDE name and shit on the good work of many past developers and other volunteers who valued things like functionality and user choice.

        1. You just created three comments under the names “clueful user”, “captain obvious” and “cluebat”. All with the same email address and same IP address. I would feel ashamed if I would have to result to such cheap trolling.

          You are not welcome on my blog. In future your comments will be deleted without any further notice. This is now already applied to your two other comments.

    5. The problem is that BKO is not a tool to measure this. Plasma has tens of millions of users, if 365 per year complain like this, it would be daft to base decisions on that.

      I understand that your comment serves your agenda (perhaps that’s why you chose to post anonymous), but that should not stand in the way of a proper design / research process. Basing design decisions on a vocal minority is just wrong, and will make our product worse for our users, not better.

      1. You ignore something very essential with this comment:

        “Plasma has tens of millions of users, if 365 per year complain like this, it would be daft to base decisions on that.”

        The very very most users give no feedback at all.

        The very most users simply use a software.

        Its most often simply a question of how intense you use a software and how easy you are able to state:

        “OK, i am fine with it” (Even when there are still some issues)

        1. And should we adjust our software for the few users who yell while at the same time maybe break it for those who it just works?

          1. Maybe there is an automated mechanism readily available to let these users post their ‘issues’ without them realizing that nobody will read them because their posts are isolated and only visible to themselves. I remember Stackoverflow implemented this to get rid of trolls / self-proclaimed I-know-whats-best-for-yous.

      1. Thanks for all your work Martin that must get very tiring.
        From my end I can see the frustration Martin has here but it shifts if we’re talking about the main menu opening when metta is pressed. Then I suddenly feel more compassion for the user…
        I wouldn’t respond in that way but I know what the frustration comes from.
        Sometimes it not being a bug is just defending the party line not explaining a rational decision.
        I recognise that this is just a perspective but you won’t convince me otherwise for my *own* bugbear.
        Putting my work hat on – the reporter doesn’t know how KDE should behave, why is that? Could KDE do more to ensure they are aware of how things should work? How do they achieve what they want to achieve without frustration? Are there adequate means of reporting frustrations without clogging up the bug system? How would people let you know they are happy?
        I don’t know who or where to thank for meta now opening the menu. So I’ll say thanks right here. Thank you.

      2. Do you guys tag these ‘feature requests’ so the UX people can have a look?

        For years as a developer I was completely hidden away from the end user and we would get ‘bugs’ like these raised. For many years I just marked them WONTFIX (as per the Tech leads direction), then one day I had to take our software out on a fairly expensive demonstration and sat next to an end user and rather quickly figured out the source of about half of these tickets.

        I started pushing for us to classify these kinds of tickets so we could figure out some commonalities. It wasn’t as good as talking to them but helped us identify areas they were struggling.

        These days I’m allowed to develop wire diagrams (Confluence/Gliffy make this trivial) to go with use cases and actually talk to my end users as a result for about half a days work, any project I start doesn’t get these kinds of tickets anymore.

        I love KDE, I really appreciate the work you guys do and one of the things I really like was the UX planning which went into Plasma 5 (reading blogs on KDE Planet). I’m not saying these tickets are right, but they might point at workflows that are different from what was expected and it might only take some small change someone to make a lot of them go away.

        Also dist-upgraded from Debian Jessie to Stretch, just wow prettier than Windows 10, faster than Windows 7.

        1. We have a keyword for usability related bugs and we tend to include our usability experts into the discussion. In this case I didn’t as well it was not a usability issue at all.

  3. Same regular experience here. You know kitchens are hot – but in the end delicious things come out.

  4. I appreciate that you (Martin and all the others) don’t get pissed off by comments like that and that you keep your good work. I use KDE since 1995 and I still love it, KDE Neon is my main PC OS.

    Thanks a lot for your great work, KDE guys!!!

      1. Martin,

        Is there no way to ban accounts from the KDE Bugzilla?

        A lot of the KDE bugs I’m subscribed to are filled with usless comments – like it’s the KDE forums. As a Plasma 5 end-user it’s really annoying to have a stream of garbage / spam comments coming into my email…

        I’m quite active in the Wine community. If people tried that BS on the WineHQ Bugzilla they would get shot down in flames!! It’s seen as a place for progressing bugs – not general chit chat… 🙂


        1. Yes, the sysadmin team can ban people, and we do it for spam and code of conduct violations. But we only do it if a developer asks for it. We can’t constantly police Bugzilla for such behavior.

          1. Sure… Hmmm.
            hings definitely aren’t working very well – in the KDE Bugzilla – just now… The barn door is wide open and the horse is galloping away…

            Maybe it could be brought up at the next KDE Hackathon? A Bugzilla filled with noise – is useless to anyone!

        2. >A lot of the KDE bugs I’m subscribed to are filled with usless comments – like it’s the KDE forums
          That’s primarily because the devs mostly don’t comment or acknowledge whether or not there is a problem. It feels very empty in bugs.kde.org.
          I have 68 open bugs reported by me – 54 of them are “Unconfirmed”. Many are like this one (the original report and a follow up comment by myself):
          I should know since apparently I’ve reported almost 500 bugs since 2006.

          Just to be clear: I think the user that Martin cites should be banned – I’ve always defended the developers. They do an amazing job in KDE!

          1. Concerning unconfirmed: you know that it has no meaning in bugs.kde.org? It’s a common misunderstanding between users and developers.

      2. Keep calm and carry on with good work 🙂
        I think that the main issue with KDE is that their is no good distribution synced with the kde released.
        kubuntu is nice but it is off sync. As a result, users report bugs which have been already fixed in the kde trunk.
        The neon project may be an answer but the last time I tried it I couldn’t install many very common qt-based software due to inconsistences in the set of neon provided libs.
        That being said, I’m happy with kubuntu. I try to look at the code and check if the bugs I want to report are already fixed.

        thanks for the work.

  5. Do not despair. You can not please everyone.
    KDE is great and KWin is one of the best and most stable parts of it. Besides, each and every fault-finder is free to fork whichever component he/she sees fit and do pretty much whatever he/she sees fit with the fork.

  6. I love KDE, it is one of the few software pieces whose I am excited each time there is an announcement. I am following `kde.planet`, `dot.kde.org` and `kde.org` only because I am eager to see what is new.

    Keep up the amazing work!

    1. In this case the problem is – as I think quite often currently – that the feature existed in the first place. Optional feature not working as user wishes. If it would not exist, we would neither have pissed users nor pissed devs by user’s behavior.

  7. Some people don’t like KDE design.
    Those people go to Enlightenment, and don’t like it’s design.
    Then they go to Cinnamon, and don’t like it’s design.
    Then they go to MATE, and don’t like it’s design.
    Then they check their email on LXDE, which they still hate the design of, and see the one actual bug they reported fixed.
    Case in point: You and J Riddell are WAY more helpful than the Apple and Microsoft developers.

  8. hm… know this feeling, while not opensource, working with customers in paid situations (as many people link this specifically with open source) can be exactly the same.

    doesn’t matter if u get bucks for it, sometimes you want to do a lot of *beep* and even more *beep* and oh there’s violence too. (being honest here, sometimes I question my own sanity while working with customers).

    so…. don’t stop working on it. kde rocks.

    *enjoy this free lasagna with beer*

  9. “The feature work exactly as it’s supposed to work. I’m sorry, this won’t be changed”

    If this were truly the case, we would be on KDE1.

    How many features that worked exactly as designed have changed since then?

    Things change with feedback and new experiences.

    I sympathize with developers, and this attitude from developers really frustrates users (the sane users as well as the trolls)

  10. Some KDE design decisions have bothered me for some time now, I do not agree with a lot of them.

    I don’t know what’s the specific case there, but I never felt the need to report a bug because of a design decision.

    A bug for me is something crashing or not behaving correctly. Not a design pattern. If a design pattern is different from what I think it should be – well, ok, I disagree with the design decision, and probably a lot of others would disagree with me. I have to state – it somewhat got better in the past years (in my opinion, especially with network management).

    In the end, if I do not agree with design decisions, I do not have to use the software. It’s as simple as that.

    Don’t get me wrong, but KDE (plasma) is a lot like a “technical showcase” for me. It’s incredible what KDE (plasma) can do, and the possibilities provided. I will never ever use 95 % (or more) of the possibilities provided. It’s based upon providing features, not users needs. My opinion – you can quote me on that.

    I did a switch in January, after running KDE (desktop) since 1998. It did hurt my heart, but with Budgie I found what I was looking for as a Desktop.

    I still use KDE software. Don’t get me wrong, there are real gems. I mean REAL gems. Dolphin + KIO/SFTP + Kate. Konsole (ye, really, I love konsole! Reason? A lot of competitors are missing “copy on select” option!). Okular – that’s a really great one too. And I don’t plan to change that. Why should I? Because they use a different toolkit and libraries than the desktop? Loading times? Seriously? Not with SSD and the amount of RAM we (me, a lot of users) have. Even developing in Qt for a living, I do not care what another developer uses as long as the software fits my needs and integrates nicely.

    As a desktop – I can’t see me going back unless they fuck up Budgie with the Qt port.

    For me personally, a lot of the KDE software stands out above their competitors. The desktop itself got a lot better usability whise, but is feature loaded to a level “just think about what nobody would ever need, let’s implement it”. As I said, my opinion.

    1. Yeah, I think that too.
      Sometimes I feel plasma has features just to have them, instead of imaging what the user wants/may need.

      I’m seing the number of bugs on plasma is decreased very much, but I still notice that every release (even point releases) contains some regressions (nothing serious but sometimes very annoying). Why we don’t do unit test? Maybe they can help.

  11. Gosh. Some people just want to complain about everything. I worked as a waiter for a while. It was terrible. Those jerks can really ruin your day.

    Thank you for all your hard work, Martin.

    Here’s something that might cheer you up. Lately, I’ve been (ab)using kwin_wayland to get X11 working on SailfishOS with lipstick.

    I chrooted into an ArchLinux rootfs and installed some packages. I ran kwin_wayland –xwayland, and behold, an XWayland window popped up in lipstick! With full multitouch input! Pinch-to-zoom works in Chromium! I can even run full desktop sessions (plasma is a little too heavy for my phone, but xfce4 worked well).

    Thank you, Martin! Now I can run desktop applications on my Sailfish OS phone!

  12. Hello Martin,

    I understand the pissed-off-ness you are experiencing. But please keep up your insightful and patient and professional and respectful attitude. It is the only way to keep the discussion civilized.

    For hopeless cases one might consider working with psychology-proofed reply templates which will explain again and again that KDE software is a community product and not every single wish can be fulfilled. Or so. 🙂

    You are a so good developer and your time should not be wasted. —-> Maybe we could establish a mechanism where you can easily delegate the “disgruntled user communication” to other people.

  13. Here is the point, they’re not 100% wrong, same as you. The point is to have a balanced view, no one is 100% wrong or right, it wouldn’t hurt to take another look into your design decision, and provide more reasoning than “it is what it is, go use something else please.”.

    Those responses are bad, but there are simple ways to prevent them in the first place, you get frustrated, the other person does too, they don’t need to be trolls to get so… If you have a reasoning, say it. If you don’t, you should think twice about your design.

    1. Please compare the tone of my reply and the reply of the user. That’s what I wanted to bring up. Obviously there were other comments before including a technical explanation! (Unfortunately not well written as Android once again changed the meaning of what I wrote, but well).

  14. On one hand I understand the frustration, on the other hand one has to say that you

    – Also quite have a history of implementing things that change workflows withoug checking first with the relevant groups (e.g. VDG) or fellow developers, then you are surprised by the backlash

    – have not been terribly kind on bugs.kde.org as well, accusing users who disagree with you (technically, friendly) of trolling and trying to harm KDE

    – are super thin skinned, and on multiple occassions have threatened to leave KDE and remove (partial) work done just because you disagree with a user

    – flat out said that you are going to reject any code that provides a certain feature or even is targeted against a specific product (!), regardless of the actual code

    And what people already wrote: if you get that kind of reaction so often that it is a “typical day”, then indeed at least part of the problem might be on your side, and you should learn to take valid criticism and change decisions if it turns out they weren’t so great.

    So: as usual, there are two sides to every story. And whilst some users indeed misbehave on bugs.kde.org (and other places), I’ve also seen plenty of questionable behaviour from various KDE contributors.

      1. No, he’s got a point.
        What if a user writes a blog post criticizing the bad behaviour of kde devs without acknowledging what users do wrong?

        Both parts are wrong, and we should take this chance to lower the tone sometimes and avoid pissing each other off.

        Otherwise, like you devs usually say to a user when he tries to criticize your work without providing a solution, “this is just a rant”.

      2. Huh, no, I think context is always relevant.
        Also he brings up a couple of valid points that you completely ignore.

        First of all, you are starting an internet pillory here, with pointing out specific users. That’s very rude, given the broad audience you have. I’ve yet to see users do the same and starting a campaign against KDE developer $xy.

        So I went and read through a couple of bug reports, and I can confirm that there is a lot of “I don’t want $x” or “I’ll change $y” with a complete ignorance of valid opinions against, up to the mentioned throwing of a trantrum. That’s hardly helping the cause either.

        So I think that some KDE people definitely need to learn to communicate better and to start listening to the users a bit more often again, especially when they have valid input and complaints, and especially before they get turned down so often that they start being frustrated and this is the outcome.

        Also I think the point of your choice of words, “a typical day”, is rather important. There are loads of other developers working on core components who seem to get way less backlash like this, or at least handle it a lot better. So while I certainly don’t think the tone of this user is appropriate, I can see where the frustration is coming from and I predict that, unless things start to change, we’ll repeat this cycle over and over until you finally do quit. Hardly a good option.


        1. Yes, that is why I brought it up. I feel the way users act in bug reports is driving away devs. To me a bug report is something very technical. But users tend to be emotional in it. This results in conflicts. Also for the use it is a one time report, but the devs have several such bug reports each and every day.

          1. Apropos Bug Reports being technical: yes and no: I personally prefer the Philips Kommunikations Industrie and Bell Labs terminology: it’s not a “Bug Report”, it’s not an “Error Report” — it’s a “Change Request”.

            The reasoning is as follows:
            The System Engineers, Software Engineers, System Architects, Software Architects, Hardware Designers, Software Developers, Testers and the Quality Assurance folks, have all done their job with “best knowledge”, “best will” and “best effort”. Therefore the delivered product is, after it’s passed the customer’s acceptance testing, what the customer wanted.

            Therefore any deviation from this is a request for change — with all the consequences which will follow.

            P.S.: The term “Change Request” also applies to the changes which have to be made during the development process — because a Tester or a Review Board noticed something which wasn’t quite as it should be . . .

            1. Don, that Software Engineering theory only applies when you’re developing software for *a* customer who tells you what they want, has the right to request changes, and gets to do “acceptance testing”. It doesn’t apply when you’re making a product for thousands of people who may have conflicting requirements. Let alone when the product is done by volunteers and offered with no warranty of working at all.

              I dare you to try filing a Change Request to Apple, or Google, or your car manufacturer because you don’t like how something in their product works…

              1. It depends on which Software Engineering theory you mean.
                In general, software engineers need to collect the views of potential customers, either by means of contractual requirements (the “big industry” case) or, by interview (take a look at how Dan Bricklin and Bob Frankston developed VisiCalc).
                In the case of VisiCalc, it was “Agile Development” with constant changes being made as a result of user comments which were actively continually collected by Dan and Bob.

                Given the lack of Netiquette used by people filing Bug Reports, I’m suggesting that, the Bugzilla platform used by KDE be renamed to be a “Change Request collection point”.

                Whether or not, the name change will cause better manners when human beings report issues they’ve experienced while using KDE applications, is something that can only be proven if the change is made.

          2. I understand the trouble that devs get (being one myself). We often try to address the technical side of the issue, but forget that users are emotionally invested in their problems, otherwise they likely wouldn’t have gone through the hoops to report it in the first place. We get so many reports that we can lose sight of the fact that there are irritated people on the other side of that report.

            We are emotional beings by nature, which becomes troublesome when we are annoyed by our tools and become irate at inanimate objects (or each other). Often finding an opportunity to vent our frustrations in ways that aren’t logical or constructive.

            Unfortunately, although it is easy to sooth the pain with a voice even over the phone (I also did tech support for an ISP). It is quite a bit more difficult to express as effectively on such a cold medium as a bug report system in text (even emoticons have their limits). Pair this with a generation of people that feel entitled to “have it there way right away” and you have a recipe for disaster.

            1. Or, are we currently suffering from a generation of human beings who are not aware of “Netiquette” and, are not aware that this “bad manners” issue is not new; from an IT perspective it’s (almost) 40 years old — in terms of written (on paper) notes and comments, it’s much older . . .

              Whether or not a disaster will occur due to the presence of this human behaviour in an IT world, remains to be seen.

          3. This pattern is an inherent problem of the internet where anonymous users can write whatever they want and get away with it in most cases.

            Wouldn’t the application of a comment filter make sense, maintained as a a secondary ‘spam’ filter so it will not get mixed with the actual spam filter. The identified comments are not shown except for the comment writers themselves.

      3. That you see it like this, confirms his statement.
        You think its just about his tone?

        His tone is like that, simply because people ignore him and his opinion. His tone is like this, because he sees changes in his probably favorite desktop environment, who dont look nicely to him.

        I guess you act similar – at least in a first intention – when something like this happens.

        Yes, you might be more developed, when it comes to a nice tone.

        A nice tone is not all. Imho 🙂

        1. The feature in question has been unchanged for about 20 years. No, there were no changes.

      4. When developers respond with arrogance and disdain to their users, it certainly isn’t irrelevant. The reason why so many people move away from a particular platform, regardless of whether they are a paying customer or not, is because even when polite and constrained queries are made, the general response is “my way or the highway” It’s deeply frustrating, more so for when we get the response, “if you don’t like it, go fork and code it yourself”, – which is absurd.

        1. Apropos developers: and, as an explanation, during my working life I was a Software Developer, a System Engineer and a Tester (ISTQB certified).

          Between Development teams and Test teams, there is often a healthy disrespect which in extreme cases verges on hate. The developers are proud of their effort and decisions; the testers are measured on the number of Change Requests submitted per week.

          At times the relationship between Engineering teams and Development teams is also “strained”, especially when the system design and/or architecture is such that the software implementation is not simple and straight forward.

          Can good (acceptable) product quality be achieved without arrogant engineers, developers, testers and QA folks?
          ** I suspect not!! **
          [But, I’m someone who was, and is, arrogant . . . 😉 ]

  15. Yes, the user’s manners are not the best.

    ** Why the world in general currently wishes to ignore the social conventions which were first defined during the days of Usenet and Bulletin Boards (BBS == bulletin board system) [Usenet: 1980 — BBS: 1978], is for me a mystery which I suspect will never be resolved — human beings being what they are . . . **

    Netiquette: a colloquial portmanteau of network etiquette or Internet etiquette, is a set of social conventions that facilitate interaction over networks, ranging from Usenet and mailing lists to blogs and forums.

    1. Ignoring the user’s bad manners [whoever it is/was ignoring the conventions of Netiquette . . . ] for the moment, there is a KDE quality issue that I feel is in need of some comments:

      1. What is “quality”? (especially “software quality” . . . )
      I addressed this issue in a presentation I made at a German software testing day some years ago:

      – Duden (the German dictionary): Quality is a state, a figure of merit, a goodness, a value. Quality may be 1st class, or 2nd class, or middle class . . .

      – DIN EN ISO 9000: Quality is the grade (the degree) which a product complies with the required features.

      – Spillner and Linz: Software Testing: basic knowledge:
      The quality measured by testing has to match the expected quality during the use of the delivered product.

      – Tom DeMarco (1987): Quality can be likened to the chocolate sauce on a portion of ice-cream: some people like a little bit more, others want a little bit less.

      – Job announcement for high level Quality Management position:
      “You are responsible for the product quality our customers expect.”

      – German butcher: “Quality which you can taste.”

      2. What is the metric which can be used to determine the value of this “figure of merit” which we call “quality”?

      First, a Requirements Engineering mantra: (Lewis Carroll) — Alice and the Cheshire cat — Alice: “Would you tell me, please, which way I ought to go from here?”; Cat: “That depends a good deal on where you want to get to,”

      My suggestion for a value which may be used as a metric for product quality:
      ** If the requirements for a product have not been changed during that product’s development then, the quality of that product is not acceptable. **
      In other words, a product with a quality of “good enough” has “suffered” several requirements changes during the development cycle.

      I have to admit that I’m unashamedly influenced by the following people:
      Tom Gilb; Dorothy Graham; Michael Jackson (not the singer); Tom DeMarco; Kurt Bittner.

  16. Hello,
    I totally understand your unpleased user. It says you it’s bad, you answer, yes, but it’s bad by design, he frustated he leaves… The thing is an adult people needs to understand before he accepts. It is different for young people so you maybe still don’t know that fact.

    You should have explained him in what your solution is good and better than its proposal. If you have no explanation (it is by design is not an explanation) then maybe even if it works it is a bug.

    Communications matter !

  17. I think that user doesn’t understand what Martin says: to me “by design” means that he isn’t responsible for how this feature works, he only makes it work.
    IMO this is not Martin’s responsibility to explain design decisions because it can take more time to explain then to design something new and people should know this, because they don’t pay for this.
    But problem is, that someone responsible for design could have made mistake or has overlooked something and for users when something works not-intuitive is treated also like a bug.

    1. Please note that design in this case does not mean “visual” design, but “software” design.

Comments are closed.