KDE Quality Team implementation
Carlos Leonhard Woelz
carloswoelz at imap-mail.com
Fri Jan 2 23:26:56 GMT 2004
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:
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
More information about the kde-core-devel