KDE Quality Team implementation

[Carlos Leonhard Woelz]

On Saturday 03 January 2004 09:50, Tom Chance wrote:
> 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.

You are right. I am aware of that. The front page should start with something 
simpler, and the guide will be simpler, bigger, and hopefully with "step by 
step" tutorials, examples and screenshots. Anyone is welcome to write these.

But why did I start with the guide? To show that the quality / janitors idea 
brings little new stuff in terms of new activity, the idea is only to lower 
the entry point, provide guidance, saying I will be here to help you and to 
give you feedback on what you did and to say what you can do to improve in a 
way your work will be accepted.

>
> 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.
>

Yes, that's the idea.

> > 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.

Listening to developers discussion is not that bad. I am a business 
administrator and I find their discussion very interesting. And we will 
attract mainly technical people. After all, the tasks for the quality team 
are abstract.
The communication between members will be done by the list.

> 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).

I like mailing lists better. You will have to subscribe to some anyway, so way 
not do it there?

> 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.

I think people should be encouraged to submit their first works to the quality 
mailing lists for peer review. Then to developers. But after a while, the 
idea is that they do fire up _meaningful_ e-mails to developers with patches, 
analysis, new documents, etc.., just like today.

Cheers,

Carlos Woelz