KDE Quality Team implementation

[Carlos Leonhard Woelz]

I have now a raw draft of the guide for new contributors, and would like some 
feedback on where to go from here.

I updated my proposal and you can find it at:
www.geocities.com/carloswoelz/proposal.html

For those who already read it, the only part that changed was the part VI, 
Required Steps to Implement the Proposal, so I am copying it here:

-------
1) Write guidelines for the usability maintainers team, stating what is the 
job, and what is required to perform it. It would be a "Quick guide to 
contribute to KDE". It would reuse much of developers.kde.org, but with non 
programmers in mind. Some items of this guide I can think of are:
	a) General explanation of the decision process of KDE. Make sure to mention 
that the way to change something you don't agree and you can't do is to 
convince people. The general rule of KDE is that the doer has most of the 
power. Status: done.
	b) Howtos links for the building process and an explanation on how to get a 
working building environment for KDE. Konstruct can be a fundamental tool. 
CVS HOWTO. Status: done.
	c) General explanation of the committing process: where to send docs, 
patches, articles, artwork, etc... TODO
	d) General information about writing docs: guidelines, Aaron Seigo's article 
about whatsthis, etc..Status: done.
	e) General information about UI design, research tips and Qt designer: doing 
a well fundamented research and comparing with other open source applications 
is a good source of ideas. Screenshots, mockups and ui files showing the 
contributors ideas always help the odds of acceptance. Status: done.
	f) Stress the importance of reading archives of mailing lists: if the 
contributor bugs the developer with non necessary questions, it will be soon 
a burden, not a benefit. Status: done.
	g) stress the importance of bugs.kde.org, and a howto on how to manage the 
information, eliminating duplicated or invalid bugs, and organizing the good 
ideas inside it. I can't stress this enough. Status: done.
	h) Communication and promotion Status: done.
The guide is mostly done. I will review it and post each part to the 
correspondent mailing list for review
The (unreviewed) guide is at www.geocities.com/carloswoelz/guide.html


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

3) Port the guide to kde.org format, and implement it as quality.kde.org (what 
do you think?) TODO

4) Start a new mailing list for the project: kde-quality?

5) Some people suggested to start a pilot program to test the program. I would 
like some feedback on that. I don't see many advantages in a pilot program, 
and I would like to proceed to the announcement. But if you guys decide to go 
with a pilot first, it is fine with me.

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.

-------

Cheers,

Carlos Woelz