Announcing the KDE Quality Team

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 or
not, in order to improve all areas of a given application (instead of
a given area of the whole project), working orthogonally with the
maintainers, developers, documenters, interface designers and
artists.

Have you ever wished to help KDE in some way, but never knew how?
The KDE Quality Team might be just what you need! People with
disparate backgrounds can join the KDE Quality Team Project, for the
development of a complex desktop environment requires a wide range of
skills. The main tool to help any application is knowing well its
interface and functions, so any user who knows and cares for any KDE
application can almost immediately help the project. Depending on the
team member programming knowledge, artistic and writing skills or
willingness to learn, there is no area of the application that cannot
be improved.

In terms of support for new contributors, the project already
offers:

In an interview conducted by Henrique Pinto, Carlos Woelz, the person who is currently putting
the most effort in the project, speaks about the
project:

Why there is need for a KDE Quality Team?

There are many people out there who want to contribute, but didn't
manage to know where to start, specially non programmers or at least
non unix programmers. To them, this is a whole new world (CVS, compiling, docbook, xhtml, etc...). I think there is no better way to help KDE
than to support these newcomers.

If you are curious about the original motivation, you can read the original
proposal
.

What was the inspiration for such a project?

When I started thinking about giving something back to KDE, I had
trouble knowing where to start. There is a lot of good information at
developer.kde.org, but
(obviously) much of it is oriented to unix developers. I felt a bit
lost, the learning curve is steep for someone like me coming from the
windows world. Also, I started working with applications I knew too
little, and with too many of them at the same time.

In which ways KDE will benefit from having a Quality Team?

The KDE developers have been doing a great job. My hope is that we
can bring the documentation, artwork, communication with our users,
and the little boring details of the user interface to the same level
of quality of the KDE applications. Also, managing bugs and wishes can
help programmers focus on fixing bugs and adding new features.

How can one get involved with the Team?

If you are an experienced contributor, and are interested in
guiding and reviewing the new contributors work, join the kde-quality
mailing list. If you like a KDE application and want to help, join
the kde-quality mailing list.

For new contributors, there are many different ways
to help the KDE project. We have a
collection of tasks, with the necessary skills on how to perform
them, and links to guides on how to perform them at the KDE Quality
Website:


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

The KDE PIM module was chosen as recommended initial target for
the KDE Quality Team because of its shorter release cycle, so things
are going faster there. There is wiki a page to coordinate the
efforts for the PIM Quality Team, where you can have an idea of the
current efforts.


http://wiki.kdenews.org/tiki-index.php?page=Quality+Team+KDE+PIM

How will be the relationship between Quality Team members and
application maintainers?

The maintainer and developers know the functionality of the
application better then anyone, therefore their help and review is
needed for all activities around that application. This stresses the
importance of doing serious work. If the team does good work, I am
sure it will be respected and helped by the maintainers.

I couldn't be happier with the response from the community to this
project. The KDE PIM developers, for instance, were planning to start
something similar to the KDE Quality Team. We joined forces, Adriaan
de Groot is the Quality Team Coordinator for KDE PIM, and they put a
KDE PIM page with information about the PIM tasks at the KDE PIM
site:

http://pim.kde.org/development/janitor_jobs/

How many people are involved in the project in this initial
stage?

Already more than I imagined. The project in integrating nicely to
KDE normal development process.

How do you envision KDE and the KDE Quality Team one year from
now?

I don't try to envision anything. What I am sure is that I will
help the KDE project. All the work put on the Quality Team (writing
guides, the website, the structure, etc...) has already produced good
documentation. I am not worried about it, because any time spent with
the project will be well spent.

Dot Categories: 

Comments

by Tom Chance (not verified)

Just a note to let people know that I have some stuff in the works on press & promotion work, specifically:

o How to write press releases, and where to send them
o How to write a good article on a KDE application
o How to get work into online/paper publications

So if you've ever considered a career in journalism, or wanted to do some freelance media work on the side, or even if you just like the idea of promoting KDE apps, then watch this space :-)

Also, people might be interested in an article I wrote on this project:

http://www.newsforge.com/technology/04/03/01/1511242.shtml

I like the article, well thought out, though I don't think you should have mentioned the programmer stereotype, be it true or not.

by Tom Chance (not verified)

Heh, the funny thing is that I didn't even say that all or a majority of hackers were "scientific atheists", nor did I imply that theists are unscientific, but I suppose that sort of reaction is always going to come from some people ::)

by Scott Wheeler (not verified)

Well, there are a few problems here -- first it should have been "scientific, atheistic" rather than the above form to make it clear that they were independent attributes.

The proper term would have been "agnostic" since "atheistic" implies an active disbelief in the supernatural rather than the more common simple lack of belief one way or the other.

And also there are a fair number of religious folks in the KDE community; I don't think that it's a useful generalization to say that KDE substitutes for religious belief aside from the social function that organized religions provide. But there KDE is more like a chess club than like an organized religion.

And to finish off the mini-rant -- you're using the term "spiritual" to describe "stuff that people just enjoy doing". I don't think that those in the community that consider themselves "spiritual" would enjoy the analogy (since I've rarely heard a person explain their religion in terms of "I just kind of like it") and those that aren't likely resent the term. ;-)

by LMCBoy (not verified)

This is very good stuff. Are there any instructions for developers, in order to have their module/application added to the Quality Team project? Right now, it looks like only KDEPIM is available for interested QT volunteers to work on.

by aleXXX (not verified)

Hi,

if you want to help, please join our mailing list

http://quality.kde.org/contact/mailinglist.php

You don't have to be a programmer, but of course programmers are also welcome.
Volunteers can work on any part of KDE they want, as it has always been :-)
It's just that for the KDE PIM project there have been some goals and tasks collected and written down.

Bye
Alex

by Carlos Leonhard... (not verified)

We decided to start with KDE PIM because of the shorter release cycle, so things are more urgent there. But we hope to expand the coverage to more mudules, making easier to new contributors to select what ot do.
Also, anyone can create a team page for his module / application, and announce it in the mailing list, I will gladly update the website with this new information.

by annma (not verified)

We already started an 'Open Tasks' page in KDE-Edu so that could be linked from the Quality main page.
We want to focuse on adding WhatThis help in each app, porting some apps to some more modern code, fixing bugs by systematically going through the bug database, improving doc (taking screenshots is an example of a non-developer task). Creating icons and pics for specific apps are also wanted tasks. There is plenty to do and everyone can find something to do in order to help improving KDE. Checking that every string is in proper english and spelled correctly is also a global task that can be done by native english people.
I hope many people will join and make a difference.

by anon (not verified)

Looks like a great source for new KDE contributers, just like the old "jobs" page used to be on kde.org (but hasn't been actively used since 2001 or so)

by David (not verified)

...but this is a ******* brilliant initiative, and it is sure to get more people involved. Now when I get this wireless network and server infrastructure up and running here I'll definitely be reading through this. Perhaps one of the problems for some are the lack of broadband access, and not knowing how to get involved and try things out otherwise. It has been for me.

by lucas (not verified)

pardon

by Pat (not verified)

on http://i18n.kde.org/doc/screenshots.php it says:
"To give our documentation a corporate look we have decided on ONE theme/style for all screenshots:
Window decoration: Keramik
Widget style: Keramik
Colors: Keramik
Background: Flat color - Color must be white"

shouldn't that be Plastik now? :)

by mooby (not verified)

And you will make screenshots for all languages for all applications ? because I don't think that each i18n team want to do another series of screenshots for all the localized docs :)

by porter235 (not verified)

OK, this has been mentioned before, but why isn't there an automated tool for taking screenshots? Then you set the script and walk away. Computer hums away while you are at work and when you get back there is a big old batch of screenshots ready to be put into files. Hell, match that up with an xml log and an xslt to transform to docbook and then do docbook to pdf. Now you have docbook, pdf documentation ready to go.

I am not able to code this so, I'll shut up now. (But I might be able to help with the XML, XSLT part of things)

by Didi (not verified)

This is a very good idea. Would this be very difficult to implement? If the standard KDE framework could provide this functionality as part of a standard test environment a lot of time could be saved and used to improve programs. I envisage a tinderbox like setup that would continuously rebuild and run kde and all apps in all languages creating snapshots as it goes. This could also be used to catch simple errors and could regularly give all the saved pictures a once over to check if everything still looks good.

(usual disclaimer: don't have time, kde programming skills or broadband access myself)

by Henrique Pinto (not verified)

No, because Keramik is still the default style...

by John (not verified)

yes, but plastik is the defacto default among users :)

by Ian Monroe (not verified)

There was some talk of making it the default default for 3.2 on this site. It seems to be the case they will wait for at least 3.3 but perhaps 4.0 before making changing the default theme, so people aren't thrown off.

by Peter Simonsson (not verified)

There will be no change of the default style until 4.0.

by Alex (not verified)

Keramik looks good, it can be refined, but it looks good and there is no point to change it so fast.

by Rayiner Hashem (not verified)

Keramik is like Luna. A few people like it, but among users, there is a very large-scale tendency to immediately switch to a different style. I understand the logistical problem of changing the default style, and agree that we shouldn't change it during point-releases. However, I actually think Keramik is hurting KDE a bit by making KDE screenshots much less appealing then they could be. I have to say I was relieved when the "Deep Inside KDE" article came out with the screenshots in Plastik.

Keramik also has some practical problems other themes don't. For example, the gradient toolbar looks strange. You've got what appears to be a curved surface with flat icons balanced on it at one point of contact. Further, it interacts badly with the "toolbar crawl" present in all KDE apps when they are resized. Styles that don't have a toolbar background (.NET, ThinKeramik) or have a very subtle one (Alloy, Plastik) make this effect nearly unnoticable. Keramik's toolbars are so distinctive that it accentuates the effect! People might consider this trivial, but people who don't understand the code can easily interpret this to mean that "KDE is slow."

by Marc Heyvaert (not verified)

An exellent initiative.

I am still a newbie and want to contribute to KDE (KOffice in particular) and during these past few months I have struggled with some of the things that are now very clearly explained on the web-page.

I have only notions of programming in C++ and I am a complete beginner in Qt, so my contributions in that area will be limited. Nice to see that there is now an additional platform to discuss what needs to be done and how it can be done efficiently. I'm sure it will enable us to exchange information in a better way.

Marc

by Patrick Smits (not verified)

On http://quality.kde.org/develop/cvsguide/buildstep.php#step5 the script to compile single KDE-modules fails:

kdedev@ip172:~/src/kde/log> more kdelibs-20040304.log
./module-build.sh: line 7: configure: command not found
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.

I think the correct module-build.sh script would be:

kdedev@ip172:~/src/kde> cat module-build.sh
builddir="/home/kdedev/src/kde/build/"$1
logfile="/home/kdedev/src/kde/log/"$1"-"$(date +%Y%m%d)".log"
moduledir="/home/kdedev/src/kde/"$1
cd $moduledir
make -f Makefile.cvs >> $logfile 2>&1
cd $builddir
$moduledir/configure --enable-debug > $logfile 2>&1
make >> $logfile 2>&1
make install >> $logfile 2>&1

Works for me!

Patrick

by James Richard Tyrer (not verified)

I am, of course, very happy to see this.

There are additional issues that need to be addressed. The most important of these is regression testing. In KDE-3.2.0 there were serious regressions that were not caught and/or almost not caught. Specific example was bug 73379.

Bug 73379 also illustrates some of the problems that the Quality Team faces -- problems with developers. Various excuses were made as to why the bug wasn't important and then it was closed before it was fixed.

It has now been fixed (and fixed in KDE_3_2_BRANCH) but it should have been caught and fixed before the release of 3.2.0. This bug was a regression; proper regression testing would have caught it. Now, the test cases should be added to a regression testing data base. So that even after it is marked "VERIFIED" if it is still fixed in the next stable release (3.2.1) that future versions will still be tested for this.

Also important is the "won't fix" problem. Yes the maintainer is in charge of his module, but if QA is going to work, he can not arbitrarily use this authority to refuse to fix bugs. Bug 53345 (which had previously been closed without fixing) is an example. My comment #10 which ended with: "Please leave it open till it is fixed" was answered with personal insults. The general issue of what to do when the maintainer says 'won't fix' and closes a bug that the QA team feels is important needs to be addressed.

In general, the 'Ostrich algorithm' is not a proper solution to any bug.

And, third, the QA team needs to be able to set the severity and priority of bugs. The most important point here is that regressions should automatically be marked (at a minimum) Priority:HI and regressions that will be encountered by many users should have Severity:major and in some cases Priority: VHI. The reasons for this should be clear to users but don't seem obvious to developers. So, if (as the some developers seem to insist) QA team members with BugZilla modify authority are not to be allowed to change these, then there must be someone in charge that *is* allowed to do it.

I anticipate that there will be problems. Some developers do not like others reviewing their work. But that is what is necessary for good quality control. Alternatively we can try to move towards TQM where the developers would be responsible for testing their own work. This won't, however, work to start with since as bug 73379 illustrates, some don't do even the most basic testing of their work.

--
JRT