KDE Quality Team implementation
Carlos Leonhard Woelz
carloswoelz at imap-mail.com
Sat Jan 3 18:12:27 GMT 2004
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
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.
More information about the kde-core-devel