Announcing the KDE Quality Team Project

Quique writes "The KDE Community is pleased to announce the launch of the Quality Team Project, a community of contributors who will serve as a gateway between developers and users in the KDE Project, and as a new way for people to begin contributing. KDE is a very attractive project, offering high quality software and is freely available. There is a lot of people who feel the urge to give something back, but stop in the middle of the way, frustrated by the steep learning curve. The aim of the project is to reduce these barriers by welcoming these potential contributors, and by offering documentation, support, and even guidance if requested. The objective is to support the new contributors, (programmers, documenters, testers, artists...). Have you ever wished to help KDE in some way, but never knew how? Keep reading!"

Comments

On the heels of ESR

[LittleLebowskiUrbanA]

This seems like it's follwing on ESR's remarks on CUPS the other day but it's not. They've put a lot of planning into this including how to maintain your own CVS and which part of KDE to target for improvement first (KDE PIM).
I'd like to see some of the numerous UI critics take part in this. You know, the ones who write scathing reviews of widgets and fonts like Eurgenia?

Re:Build it, and they won't come..

[LMCBoy]

That's really cold, man. You paint the KDE project as extremely elitist, when it is actually totally the opposite. KDE isn't some exclusive club of core people, any developers are welcome to join the project at any time, and have always been welcome.

Sounds like KDE is looking for folks to come along and do all the thankless, boring shit.

You have it totally backward, actually. The Quality Team project was intiated to include the large number of non-developer people who have been saying that they've always wanted to help KDE, but don't know how. KDE-QT provides a framework to actually include these interested and passionate contributors into our project.
They asked for a project like this.

So you see the QT tasks as boring grunt-work. Fine, then maybe KDE-QT is not for you. But there are those who excel at this kind of thing, and actually enjoy it.

Re:Build it, and they won't come..

[ErichTheWebGuy]

Thank you!!! That's exactly what I was trying to say. I am a novice programmer, and have little if any to offer to the KDE codebase. But, I would love to contribute and have extensive experience in things like customer service and communication. The KDE-QT is a FANTASTIC idea!

Some backgound information about KDE and usability

[falonaj]

Being a KDE contributor myself, I feel the urge to correct some of your statements and agree to others.

GNOME has had the Human Interface Guidelines for over a year and a half now.

KDE has User Interface Guidelines since more than 4 years. These guidelines are a bit outdated, but they are followed by almost all applications within KDE. This is one of the reasons why KDE applications are quite consistent with each other. KDE has been dedicated towards usability since its foundation, but usability was never the only goal. KDE was never perfect, but its usability has been constantly improving every version. Compared to most other PC software, KDE has always been doing reasonably well in terms of usability.

The whole project is dedicated toward usability.

True. The GNOME project made a good decision when they introduced HIG, even if many GNOME users were very angry at the time. Removing functionality was one of the main methods of solving GNOME's early usability problems, which should only be done if there is really no other way to solve usability problems.

Most people complaining about KDE's usability are suggesting the same strategy for KDE. I don't agree with this. Solving usability issues in other ways is more difficult and takes more time, but the end result will be better if we stop telling others "I know better than you that you don't need this". But anyway, I agree that having good user interface guidelines is important.

Don't get me wrong, KDE has some inovative technologies behind it, but even 3.2 is miserably lacking in terms of usability and style. IMHO, this "Quality Team Project" looks more like an after-thought or a lame side project than a redirection of the whole project.

My impression is very different. The Quality team idea has been greeted with a lot of very positive responses among the KDE developers. There is a lot of interest in this within the KDE project.

The Quality Team is not a QA project

[cwoelz]

I am the one who is currently putting the most effort into the KDE Quality Team implementation, so I am qualified to speak for the project:

Let's start by making something clear:
The main idea is not to build a QA project inside KDE. The main idea is to support and embrace new contributors with any background, and help to organize their efforts. For instance: Any doubts about the docbook? We are glad to help. Do you want feedback on your work? We are happy to provide. Looking for guidance? Hop in!

We don't want to point what is good for you: we try to present you with a long list of things one can do to help, and organize these efforts.

The recommended approach for non programmers is different from other projects: it is more like the project manager in a company than of a task specialist. In other words think of acting upon the whole of Kontact instead of acting upon the context help for the whole KDE project. We recognize that the main tool for helping an application is knowing it well. A quick look at the activities list, presenting the requirements for performing the tasks, is sufficient to prove that.

http://quality.kde.org/develop/modules/

Yes, the activities include QA. But this is just one of the activities. Hope this helps to avoid confusion with GNOME's bugsquad (also nice, but not related: it is a different concept).