KDE Quality action: looking to the future

[Carlos Leonhard Woelz]

On Wed, 14 Jul 2004 16:29:13 +0200, "Tom Albers" <tomalbers at kde.nl>
said:
> Op woensdag 14 juli 2004 13:29, schreef Tom Chance:
> > I'm intending to use the talk to try and persuade developers to co-operate
> > with us. Off the top of my head, that will mean asking them to:
> >
> > - Keep up-to-date task lists
> > - Have someone from their team on the quality mailing list
> > - Think about, and be ready for, contributions in promotion and
> > communication
> 
> Maybe it's not so useful for your presentation and I consider myself
> pretty 
> new, but one of my thoughts is that maybe it's an idea to create some
> sort of 
> 'emergency-rescue-team' (or maybe this is what kde-quality is about or
> should 
> be about). A group of people, with some time, who can jump in there where
> a 
> problem appears. 

Well, the quality teams are a kind of emergency-rescue-team. Sort of. I
will explain it better below.
 
> But I would organize this the other way around, instead of creating yet
> an 
> other mailinglist to monitor for developers, I would ask certain quality 
> members to join in on the different devel-lists. 
> 
> They can then filter certain problems, common misunderstandings, see bug 
> reports which are a duplicate for the tenth time, and so on. They can
> then 
> check if this is clear enough in the documentation, maybe mark some bugs
> as 
> duplicate, create a howto on the website, etc. If there is a bigger
> problem, 
> they can call in the rescue-team to create/organise some documentation, 
> create/organise a contest for a splash screen, et cetera.

I am not sure about "doing stuff only when called" . It does not scale
so well. See below.

> So instead of asking developers to join the quality list, maybe it is an
> idea 
> to make the quality-team the center and from there on spread the wings to
> the 
> different developers (|| ~mailinglists).

Thanks for the suggestion we already do that :)
The quality team integrates to the normal KDE development process. That
means that we already discuss the application issues in their respective
mailing lists.

This list is to support new contributors, to inform people about tasks
open, and to coordinate the work, not to take the place of the other
mailing lists. I don't expect this list to be a high traffic list. We
are fortunate enough to have very experienced KDE developers on this
list. I believe the list can answer most KDE technical questions.

What Tom was asking for is at least one developer from each project, in
order to help coordinating the quality efforts. Also, we hope that the
developers (us included) will to help to create and maintain the list of
tasks available, like the pim task list:

http://wiki.kde.org/tiki-index.php?page_ref_id=157

It is easy for the maintainer or for a developer to fill this info, with
the status for his app.

The task pages are a nice invitation for new contributors. We got a some
new people for this release cycle, and the task lists were fundamental
in this process. I hope we can do even better for the next release
cycle.

Here are other task lists for other modules:

http://wiki.kde.org/tiki-index.php?page_ref_id=107

> From there on, some task list could be created... Last week or so, I was 
> wondering which documentation was unmaintained. Maybe I would like to 
> maintain the documenatation for an application. I looked at the site and 
> found some information, but this was outdated. But someone who is looking
> for 
> this type of information should find it, I think..... But I understand 
> everybody is working very hard just before the message freeze and I'll
> check 
> the website at a later time... 

Yes, there is no sense in updating the docs list just before a freeze.
But at least the pim page is not so outdated. AFAIK, the empty spots are
still empty. And most of the contributors who are listed there are
really helping out.

About the KDE wide 'emergency-rescue-team':

Helping out one application is like opening the doors to a small new
world :) To write the docs and whatsthis for KPilot, I had to learn
about the Palm OS databases and application formats, Palm DOC, the Palm
usage patterns (I had to buy a Pilot, I wasn't even a user), conduits,
etc. I tested most of KPilot's functionality just to understand it, I
checked gnome-pilot and JPilot to get a feel of what similar apps are
doing. To help Cervisia, I had to read a lot of CVS documentation, etc.

You can't jump to an app and be productive instantly. The KDE wide
'emergency-rescue-team' does not scale well. It is better to look after
an app you like and or know in the first place.

However, you are correct in the main argument: the quality team is a
'emergency-rescue-team', but one application at a time. The idea is to
find the loose ends and tie them. Docs and whatsthis are missing? Let's
create it. Bug management is needed? Let's do it.  New artwork is
required, let's create it, or at least find interested people to do it.

Cheers,

Carlos Woelz
-- 
  Carlos Leonhard Woelz
  carloswoelz at imap-mail.com