KDE Quality Team implementation
tomchance at gmx.net
Sat Jan 3 11:50:05 GMT 2004
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 :)
More information about the kde-core-devel