Eep! EEp! EEp!

Why should we care?

Eep! EEp! EEp!

Too often we underestimate the power of a touch, a smile, a kind word, a listening ear, an honest compliment, or the smallest act of caring, all of which have the potential to turn a life around.
(Leo Buscaglia)

Don’t worry, this post is indeed KDE related.

No one would probably disagree that one of the most important aspects in open source is a healthy community, full of users and developers/contributors, each one caring for each other in any way possible. It is not about demanding a certain piece of functionality or behaviour, but working together for a certain target and a nice atmosphere.

We want to start a new initiative, a new fresh look at things. What are we offering? What are we doing good, but also what bits are missing? where do we fail? Sometimes it’s just the easy path to look at our own needs and not ask the actual users what they need.

We worked through that awesome book Lydia wrote, and realised that we are probably not listening thoroughly to all users and we want to change that.
We will start to listen, we will try to make a difference. Small steps, we can’t do it all in one day.

Ok, so we already thought of some items where KDE can improve, but that’s just what *we* have thought, and that’s just not enough, we need your feedback. Let’s give you our 5 minute brainstorm items:

  • We currently mainly communicate with users via This medium really is not the best tool for that. It is not user friendly.
  • We have a great but developers don’t use it that much, nor is there any links from applications towards Userbase.
  • We are in no way effectively using web 2.0 technologies, for example live chat, to provide direct support to users from within our applications.
  • We have an more than awesome where users can help each other, but it is not used a lot by developers, not linked from within applications, nor used in any marketing or promo efforts.
  • In that same forum there is a great system to talk about features, measure popularity of such new features and provide a completely documented feature towards developers. Not a lot of developers are using that. Instead features still are reported to
  • There are new tools out there, for example for crash aggregation. We don’t use those, instead we use for those too. Crash aggregation would improve the usefulness of, by minimising duplicates and bugs belonging to other components.
  • Overall websites are a very important part of outreaching to the community. They are not effectively used by the developers and lack important parts of information
  • Lack of social media integration within all apps for example, or a ‘feedback’ tab as you see on many, many sites.

The greatest degree of inner tranquility comes from the development of love and compassion. The more we care for the happiness of others, the greater is our own sense of well-being.
Tenzin Gyatso

All these ideas have let to the formation of a Special Interest Group called ‘water carriers’. Why water carriers? There is a certain group inside the KDE community which is not related to any development nor is a plain user group. Those who try to support users on a daily base. Compare it with the Tour de France, there are some riders that just bridge the gap between the source of the water (cars behind the riders) and the people riding with Moto 1.

We set a goal to focus on these items:

  • Come up with proposals that will create communities around applications.
  • Make sure users have a pleasant experience when reporting bugs, crashes and wishes.
  • Think about how KDE should communicate effectively and efficiently with users.
  • Make sure developers are communicating with users effectively to solve problems with applications.
  • Motivate developers and users to improve the available resources / knowledge about applications.
  • Lower the barrier to get quality support
  • Investigate and implement new technologies.

Does this make any sense to you? Are you willing to help? We are thinking of gathering a special group of users and developers which will provide feedback to us. Do you want to get involved? Do you want to help to shape the future of KDE? What are your ideas? Do you like the ideas given in the above list or is it just a waste of time? We are looking forward to as many comments as possible, we want to make KDE rock, but we need you to tell us what you need.

With the gift of listening comes the gift of healing.
Catherine de Hueck Doherty

(thanks to Tom Albers and Ben Cooksley for thinking and writing about it with me)

photo by: Carly & Art

24 thoughts on “Why should we care?”

  1. Hey neveradmin, great post. Where do I sign up?

    I think that calling the whole idea great would not be enough. We, as a free software related community need to make things easier for everybody, and the sort of devs-users-docs-bugs-wishes-apps integration that you are talking about might be just what we need to grow further.

    Maybe a starting point could be developing a KDE API that could be used by all Kde, Qt, and any application to provide feedback (in “stars”, for example), a link to a XMPP or IRC chat channel, to post a formated bug or wish (without having to create a user account or having to register to a tracker) or to easily help with something, like a translation, implementing a missing piece of documentation or help.

    I really think that many times some users (not devs or tech-savy) see something that could be fixed or improved but give up when confronted to a web registration form, bugzilla, etc.

    Maybe this KDE user-community integration API could use existent technologies, like Akonadi and Telepathy, to make it easy to “connect” and be available for group chat in specific channels. Maybe it would even make it easy to copy & paste questions and answers from the chat to an indexed knowledge base for that app.

    Anyway, I see lots of great opportunities to make KDE and even the whole free software ecosystem better.

    Best wishes,

  2. I like the idea of leveraging the ‘water carriers’, but of course I consider myself to be one, so… 😉

    The frontline people who support users on IRC, forums or face-to-face, install GNU/Linux/KDE for their friends and family etc., often have good insight into what problems are the most important to “normal users”, and hindering greater popularity of KDE. And often these problems are small things which could be fixed fairly easily.

    Perhaps it would be best to use the ‘water carriers’ as a kind of filter for the “normal users”.

    1. This is sort of happening right now with the introduction of this post. 😉 And they (we) would like to improve the overall situation and maybe – in best case – make the gap between developers and users a little smaller.

  3. I guess that’s what KDE users really need/want:

    1) Rock solid environment (KDE should never crash and should instantly recover from any errors)
    2) Few or no errors if possible
    3) Visually topnotch ( – really??? During 15 minutes of usage I can find a dozen more similar visual glitches and problems)
    3) As low as possible memory/CPU footprint, the ability to easily disable all semantic/social/etc BS – I don’t want to run a MySQL instance for fancy things I’ll never use
    4) More applications (KDE still lacks KSensors, there’s no webcam application, no scanner/webcam application – really??)

    1. “should never crash”
      Yeah, we all wish that would never happen with any software… but it does from time to time, with any software…
      As for the other things, what really needs to be understood is
      1. some bug might hit you more than other users, and it is quite hard for devs to prioritize one bug or the other, especially when they are working at it in their sprare time
      2. as you probably noticed with the mentioned bug, it was not reproducable. Might sound weird, but it happens quite often. And how would you expect a bug to be fixed if you can’t even reproduce it.

      So in this case it is absolutely necessary to improve the overall reporting process. But as you can see in the list provided, this is indeed one of our targets.

      For missing applications, yeah well, obviously no one is really interested in working on such an app. Who can blame them. Projects are usually started for the fun of it.

  4. It would be great if there was documentation for building and running the latest KDE from git for the latest distros. I’ve documented what I had to do on Fedora 17 but the techbase wiki is not editable. I’ve asked for help on IRC on why feature X doesn’t seem to have been compiled and saw only dead channels. I probably won’t give the forums a chance now (or ever) since I doubt developers will ever use them since they have mailing lists. Eventually, if by the beginning of the next weekend I haven’t either forgot what I was doing or lost interest I might send a message to a mailing list asking for help. Even that is a bit intimidating because who wants to ask “How do I build application X?” when the answer is probably clearly outlined in some up to date documentation that I missed. Bugzilla is a mess.

    In short I’d like to help out but I usually don’t since simply getting up and running is an impassible obstacle.

    1. The benefit of water carriers is, they are most likely able to help you, even if there is no dev around, especially in a case like yours.
      The forum is indeed a place where many of us are hanging around. And if everything that stops you from helping out is just some documentation on building apps or the environment, i am sure we can find a way to easily improve that.

      For that specific case i know there are indeed some outdated informations on techbase. But that can be sorted out. Guess that also refers to one of the points on our list.

  5. Hi, I’m an old kde-user.
    If you ask for suggestion to improve kde, maybe listen at the “voice of people” on internet:
    – is slow and overbloated
    – disable akonadi/nepomuk
    – lot of bugs

    In my (not very professional) opinion some developers (most are involved on PIM projects) has a different target form “common” kde-users so it seems that they are trying to “migrate” users on something that is unfinished (with lot of bugs) and unuseful (if you use kde for personal pourpose).
    So my suggestions for improve kde are:
    – choose the lighter option available (don’t use MySQL, use sqlite instead)
    – make semantic-desktop optional not mandatory (I don’t know if is possible to convert akonadi/nepomuk on a plugin-based framework: so you don’t need MySQL and akonadi “up and runnig” only for reading your old e-mails)
    – new features are welcome only if the basis is stable and rock solid (and maybe even debugging is easier)


  6. As long as people like Martin Gräßlin publicly rant about “the users” being too dumb to understand and many other unfriendly things, I think you shouldn’t worry that much about the rest…

    1. This is not helpful, and a rant on itself at best.
      Frustrations are coming up on both sides. Now we can either drown in those frustrations or try to come out and improve it.

      It doesn’t work like “developers shouldn’t rant”. Of course not, but users do the same all the way along. Especially with arguments that are not researched very good (i am assuming you refer to the comments on a german linux news site about the latest release).
      Wouldn’t you get frustrated too from time to time, after years of ranting about your baby? 😉

      There is a huge difference between giving feedback and giving GOOD feedback.

      1. Whoops! Here we go again! ALL user feed-back is good feedback. It tells the developer what effect the product has on the user. If the user is sufficiently angry to “rant”, then the negative response is, presumably, all the more important to the developer. If a user is only mildly irritated, then fixing the problem is possibly less urgent or vital.

        On the other hand, a user who is told – even politely – to RTFM is being treated as a low-grade developer, rather than a user. The product should work, and work correctly, without the user being required to indulge in self-education or research into the developer’s area of expertise. When a developer tells a user to RTFM, then we know that, at the very least, the user interface is inadequate. The user has other problems to address, rather than fiddling around with a piece of software which is – apparently – under-performing.

        In the end the two rants have quite different outcomes. When the user rants, then the developer has the opportunity to learn about the product from a different point of view. When the developer rants at the user, then the user will usually just go away and find a better product.

        Don’t sneer at the user who has neither the time nor the inclination to diagnose the problems with your software – this may well be someone who is much smarter in their own field than you are. Just listen, swallow your annoyance, which is probably guilt-driven, and fix the damn thing.

        Or is this all to be a one-way street?

        1. “Don’t sneer at the user who has neither the time nor the inclination to diagnose the problems with your software”
          Neither might the developer have the time or motivation to diagnose the problem of a particular user, especially when it was provided as rant, without any real information about how to reproduce it. Neither does it help to just state “it is broken”.
          So no, this is indeed no one-way street.

          But this post is not about specific issues (which come up every once in a while – we all are humans) but what exactly is missing and how it can be improved.
          Bug reports/request/wishes NEED to be done and handled in a specific way, else you are indeed left with – tada! – rants all over the place from both sides.

          1. Well, I wish you all the best with your review. I hope that you will follow up all contributions, however inarticulate or heated they may be at first. After all, the more heated the interjection, the more unhappy the user.

            I guess the trick is not to confuse “water carriers” with fanbois. And you would never do that.

            Would you?

      2. Yes, I admit that my comment was a rant itself, probably shouldn’t have written it the way I did.

        But I think it IS a problem that some developers, as the one example I brought up, don’t take users seriously. He has, in various blog entries and the comments sections of these, acted like a “user” is some kind of inferior human being, and developers have to be shielded from their bug reports, assuming a user doesn’t know or care about the technical background of a program.

        This is wrong in many cases, and it doesn’t encourage me as a user to invest time in writing a good bug report and providing further details, testing etc… If I don’t get taken seriously anyway, why should I care?

        1. Well, that is the reason for such an iniciative, and i have also heard many times the other way around.
          So yeah, this should tackled. And i hope we can come up with sensible ways.

        2. I’m sorry that my blog post have been persumed by you in a way that you think that I consider users as “inferior humans”. Of course that is not the case. Just think about it: would I write software for users, adding features I do not need myself, if I would consider them as inferior humans?

          Now what is true is that I think that developers need to be shielded from users. Not because they are inferior, but because from my experience it is not helpful to have users reporting bugs (or feature requests). What we need are water cariers transporting the bugs from the user to the developer in a way so that the developer can actually do something about the bug.

          I have been stating for quite some time that we need a first, second and third level support (you can find that in my blog posts). And I’m quite sure that Ingo’s blog post is at least partially based on my ideas. For example I contacted the forum’s team quite some time ago with the idea to have “bugs” for KWin being reported in forums and then “carried” by the second level support to us developers.

          Btw. part of increasing user developer interaction also means that users should not write that developers consider users as “inferior humans”. That’s honestly quite an insult and clearly violating KDE’s Code of Conduct ( which states to be respectful.

          1. You are indeed right, quite some of the things you posted lately are the base of this idea, even though we as water cariers notice these things for a longer time already. 🙂

            But that is okay, we are here to solve that problem. As for the several levels of support, this exists already, it might just not be used in a sane way, or maybe not even known about.
            Speaking about the webteam, we have several coders, who try to provide a certain platform for a certain need. Then, we have a bunch of editors, who try to write good documentation for certain apps. Along with them there are even translators, not part of the core kde translators, who try to translate the above documentation to their language. And finally, we have a set of moderators or webadmins who try to keep every communication in a sane way, thinking of the forum for example.

            It probably just is a matter of being aware and using it. I am not talking about you in particular, but just trying to make any reader aware.

            Oh, and thanks for highlighting the CoC, i should probably add that as rule here, this blog is new 😛

    2. Show me where I have ever called a user “too dump”. Also please show me were I am unfriendly. I never insult anyone, I’m very carefully what I write because I know I am a representative of the KDE community.

      Nevertheless I won’t shut my mouth when KDE users are extremely unfriendly towards the developers up to the point that I question why I am actually volunteering time.

  7. couple of wishes…

    Klipper: please add STATIC ITEMS, I need some items to be always in the Klipper (e.g. couple of times a week I have to enter my 32 characters gmail password… and I don’t want to copy it from a file located on external hdd. that’s why I use clipit in KDE (a gtk app that has that feature!) how it looks in clipit:

    Ksnapshot: please add uploading to image hostings… I have to use shutter with tons of dependencies to gtk instead…

    Telepathy-KDE: please PLEASE PLEEEEAAASE add client detection for ICQ, please do so!!!!!!!!!! or write a patch to haze or to libpurple. I’m very unhappy with such a simple feature… which is used in Miranda, QIP (windows IM clients) they JUST DETECT the clients of your icq contacts… very useful, if you want to send someone a file and a link, AND YOU SEE THAT THIS PERSON IS USING A MOBILE CLIENT, and most of the crappy mobile clients even don’t notify you that someone sent you a file or a link… and I have to wait for response… but user even doesn’t know about it… the working example can be found in qutim (Qt multiprotocol IM client) it supports this feature, and it looks like: here are sources of this plugin written in Qt:

  8. Hi, we are not asking to list your personal private wishlist or your list your personal itches. There is no need to copy and paste on this blog 🙂 Though general problem area’s are nice to know. Akonadi and Nepomuk are noted.

    Although noted, we are more looking for feedback how we can improve KDE. Re-read the first list given in the blog. Can you think of items missing from that list?

  9. I think there needs to be entities that can assign/provide resources or incentives to fix bugs and glaring deficiencies in a timely manner. Resources might be bounties (cash or prizes), student internships, or atta persons. Seems that waiting for devs to find the time and/or inclination isn’t always a viable option. These entities would be focused on various segments of the SC (plasma, KDEPim, Kwin, multimedia, etc…..).

    As brainstorm and wish lists are not viewed as optimal maybe some kind of give and take with an app and it’s dev’s on irc or the forum can lead to a creation of a poll of priorities for that app. If the priority poll is created from a give and take with devs maybe a better understanding of both parties will result in a better, more useful product

  10. This is a wonderful initiative. Users are our capital and for our community it is a very strong motivation to create a product, which is useful and enjoyable for our users. Sometimes this is not easy, as we have to bridge gaps which are between users and developers and other contributors. There might be technical barriers, communication barriers, or simply barriers of misunderstanding. Creating a group and initiative to get across these barriers in a better way is great.

    One area which I think is important is designing and implementing our software in a user-centered way. Observing users, finding their needs, creating solutions which cater to these needs, knowing our users, using personas to represent them, doing user tests to find out, if our assumptions hold in practice, and many other things we can do to create software, which meets the goals of its users, all these things.

    Improving communication with users is also always a good idea. We probably can tune our tools to make this more easy. But in the end the most important thing is that we simply talk to each other, with respect, and pragmatism, and find the best solutions in a collaborative process.

    1. we once had the idea of some sort of receiption, for any sort of communication. I think that deserves some further thinking indeed. Like a central place (no matter of the medium, irc, website, whatever) to guide the interested party further.
      “you have a problem with kxxx? please post on #kde or the kde forums” “you have a wish for the pastebin widget? then please try bko or brainstorm or xxx mailinglist”.
      Sort of like that 🙂

Comments are closed.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.