KDE Quality Team implementation

[Tom Chance]

On Friday 02 January 2004 23:26, Carlos Leonhard Woelz wrote:
> The (unreviewed) guide is at www.geocities.com/carloswoelz/guide.html

Though I think the guide reads very well, it does look like quite a scary 
document! If we are trying to attract the kinds of people who lurk on 
dot.kde.org, kde-look, maybe even slashdot and beyond, the web site ought to 
*attract* people to joining the scheme, and so should be presented in a 
friendly accessible manner.

Of course, I haven't seen how the whole site will look, but I'd suggest a very 
simple "front" page with a diagram showing where quality teams fit into the 
KDE project and a short description of them, explaining the kinds of things 
quality team members do (i.e. a very short version of '3. The KDE Quality 
Team HOWTO'). Then the guide you have written should be split up into four 
pages, and linked as a reference guide for those already involved, or for 
those who have decided they want to get involved and want to look through the 
details of what they'll be doing.


> 2) Accept criticism about the model proposed, and correct the model.
> Status: No criticism yet

One thing I wondered about was: how do team members communicate? From your 
model they are positioned in between developers and the outside world, and so 
both developers and the outside world ought to be able to communiate with the 
teams easily. At the same time, the team shouldn't have to listen to the 
developers' coding discussions. They also shouldn't need to be flooded with 
emails that don't concern them; you or I might not mind downloading 40 emails 
and deleting most of them, but from experience running grassroots 
organisations a lot of people really would mind a lot, and would be put off 
by the prospect, or quickly leave in annoyance.

I think the kde-forum seems the most appropriate place for the majority of 
quality team members to communicate, whilst lurking on bugzilla, the dot, 
kde-look, users mailing lists, etc. where they have the time. If quality team 
members could then submit agreed proposals to the relevant mailing list 
(-devel, -usability) that would provide the interaction between quality teams 
and developers (who can always CC followups back to the quality team member 
who submitted the proposal).

The only problem I see with that process is that it is more beurocratic than 
your suggestion of simply subscribing them to the mailing lists that already 
exist, unless the team members are encouraged to simply fire off emails to 
mailing lists without consulting the rest of the team, in which case you 
possibly subject the developers to more emails and less coherent messages 
from their quality team.

> 6) Announce it widely: we can post it on the dot and submit it to other
> news sites as a link. Or I volunteer to write an exclusive article based on
> this paper on a bigger audience news site (OSNews?) to reach a bigger
> audience, and the announcement on the dot would link to this article, the
> new site and the guide.

I already offered my help, as you may remember :)

Tom