[kde-quality] Quality Teams article, first draft

[Carlos Leonhard Woelz]

On Saturday 21 February 2004 15:13, Tom Chance wrote:
> Hello,

Hi Tom!

> Attached is a first draft of my article on the Quality Teams Project. I've
> not read it through properly yet, but I thought I should pass it on to see
> if people think I'm doing something drastically wrong with it before I
> finalise it!

You will never do anything drastically wrong ;)

While reading the article, a doubt struck me: Is your article an opinion 
piece, or an announcement?

Before entering in the details of your article, I think your article is an 
opinion piece. Therefore, I don't think I am entitled to "correct" your 
ideas, only to give you suggestions. You could make more clear that these are 
your opinions, not a collective statement. For instance, replacing "will" 
with "should", and using more the first person.

Now some comments:

1) You describe well the objectives of the KDE Quality team:

"The Quality Team Project provides an easier way to become involving in 
developing KDE's codebase. Through working in a Quality Team, an individual 
can get to know a particular application well and its developers, and learn 
key skills such as using CVS, using KDE's bugzilla, preparing and applying 
patches, and potentially more. Rather than having to jump straight into 
writing C++ code, if you're a budding code monkey you can move into your 
desired position in easy steps, and no doubt have a much greater chance of 
contributing well written, appropriate and worthwhile code that will get 
accepted."

I would put this in front of the gateway part, as the gateway is a desire, 
that depends on the developers will to work together and on the ability of 
the team members to process the information into something meaningful to the 
developers and communicate it in a reasonable form. In other words, lowering 
the barriers is a reality, the gateway is an objective. Also, we should say 
that the gateway works both ways: trying to bring user feedback to the 
project but also educating the users in the ways of open source, Bugzilla, 
volunteer work, doer power, etc...

2) I don't quite understand what you mean here:

"Given that projects, including KDE, are already very social beasts, where, 
you might ask, does the Quality Team Project come in? The answer is 
multifarious; most importantly, it provides a structure that will facilitate 
and direct discussions in a way that is more conducive to the discussions 
themselves, and to things actually being achieved based on those discussions. 
For example, rather than idly pondering the UI of an application on the 
developers' mailing list, and occasionally reading users' thoughts on sites 
like the dot, developers and the public will be able to feed thoughts into 
the Quality Team, who will handle and direct the discussion, and ensure that 
the outcome is a series of recommendations, or a conclusive end to the 
discussion. Discussions, in other words, will become more purposeful, and 
will be more open to time-pressed developers and previously intimidated 
and/or time-pressed users. "

Do you mean that it is part of the quality team tasks to organize the users 
discussions in something meaningful, or to teach them to do so? (Via 
bugzilla, usability reports, wiki, etc...) Or both? If it is both, I agree. 
But the regular channels of KDE should be integrated, we shouldn't create a 
totally separate channel.

3) 

"Another facet of the social benefits of the Quality Team Project is the 
democratisation of the social side of the KDE Project. As I have already 
hinted at, not every can participate in discussions about KDE, nor in 
discussions that KDE developers have on other subjects (an important aspect 
of the social side of Free Software communities is that discussions aren't 
forceably limited to work). But by setting up Quality Teams, KDE is opening 
the door for many more people to join up and take part in discussions without 
needing in-depth knowledge of coding, and those teams can then relay these 
discussions onto other users so that the project as a whole becomes more 
transparent. Transparency and openness is about more than simply making it 
possible for people to look inside, it is also about working to remove the 
barriers that stop people from being able to do this. "

I don't see how the quality team is gong to bring more transparency. The KDE 
project is already very transparent. What the Quality Team will try to do is 
guide the users into producing hard data, meaningful analysis, not only 
opinions. This way, there is a chance of convincing the developers. It's 
important to not that even if you convince a developer, there is no guarantee 
that something will come out of it: someone has to take his free time an 
implement it. And in an ideal world, the user should see it as something 
normal.

4) Political part: I agree, but I wouldn't call it political. Why the 
developers sometimes seem to not being listening? I think it is more a 
question of time than of politics. I would call the section "Organizational", 
or another name.

5) Spiritual: I like it very much! Indeed, you catched the spirit of the 
quality team. I have never worked with computers or OS in my life. Why am I 
interested?

In general, I like the article very much. I think that it will be even better 
in in first person, as it would invite people to discuss.

Cheers,

Carlos Woelz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: signature
Url : http://mail.kde.org/pipermail/kde-quality/attachments/20040223/66375ec5/attachment.pgp