Lessons to learn from the KDE Quality Project

[Elijah Newren <newren math utah edu>]

Hi,

On gnomedesktop.org, in the article about GNOME-love, someone asked a
question along the lines of, "Wouldn't it be nice if GNOME had something
like the KDE Quality Team to help those who can't program get
involved?"  Of course, we have had such a thing
(http://developer.gnome.org) for years, but there are a number of things
that KDE does different and/or better that we should at least consider
and that we could learn from.  Since I know that some people don't read
gnomedesktop.org (and since a news site is a poor place for this kind of
discussion), I thought I'd post my comments here.  Points of possible
improvement:

1) Inclusion of Beta testing. This is partially covered by the Gnome
bugsquad, but the bugsquad concentrates more on triaging bugs (i.e.
keeping bugzilla sane). http://www.gnome.org/start/2.5/helping.html
contains a link to Andrew's Testing Gnome guide, but that should be
including at developer.gnome.org/projects. 

2) Including "communication and promotion" as a project. KDE in general
does a very good job of promoting their software and their project. I
believe GNOME could benefit from some of the same advocacy. Sure, we
have some, but it'd be great to have a project put together with HOWTOs
and such, a mailing list, a web page, etc. and linked to from
developer.gnome.org/projects. 

3) Tasklists for individual components. A perusal of the KDE Quality
Team site shows that they're trying to create tasklists for individual
programs/projects inside KDE; these tasklists cover how well specific
parts are documented and what needs improvement, to specific portions of
applications that the developers want tested. Granted, following the
links this far show that a lot of things are empty or only have a
skeleton, but it looks like they're working on continuing to improve
this. [I'm not sure this would be feasible for us to keep up-to-date, or
if it'd even really fit in with our current infrastructure, but I'm just
throwing it out as an idea]

4) Up-to-date pages. Part of this is a given since the KDE Quality Team
is new, so it's unknown at this time how well the web pages will keep up
to date. But, it is clear that some of the web pages from
http://developer.gnome.org/projects have bitrotted. In particular, the
Gnome Packaging Project is obviously out of date.  It's understandable
since the maintain has a million other tasks on his plate, but in cases
like this it'd be useful to at least provide a disclaimer on the page
saying it is out of date so that people don't distrust the other web
pages that have been kept up. 

5) Louder active recruitment of those that want to help. The fact that
many were unaware that GNOME had the equivalent of the Quality Team in
the combination of gnome-love & http://developer.gnome.org/projects is
*really* sad.

Comments?
Elijah


P.S.  I hope I'm not making a fool of myself again (i.e. the bugzilla
thread and me guiding people to the wrong mailing list, among other
things), but I'm posting to this list instead of gnome-love.  I'm doing
so because gnome-love concentrates on the specifics of how a beginner
gets started, whereas this list seems more appropriate for a high-level
overview of what kinds of projects desktop developers think we should be
helping beginners to get started with.