[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KDE Janitors (QA?) Proposal
From:       "Luke Chatburn" <luke () linuxcomment ! com>
Date:       2003-12-19 23:49:32
[Download RAW message or body]

Hi Carlos

You might want to call it the KDE Training Team, or the KDE Learning Team.

Those will be more receptive in business environments and are generally more
obvious :)

-Luke

----- Original Message ----- 
From: "Carlos Leonhard Woelz" <carloswoelz@imap-mail.com>
To: <kde-core-devel@kde.org>; <kde-usability@kde.org>; <kde-i18n@kde.org>;
<kde-doc-english@kde.org>; <kde-debian@osite.com.br>
Sent: Friday, December 19, 2003 10:54 PM
Subject: KDE Janitors (QA?) Proposal


This is an updated proposal, with some feedback that I got. By accident,
kde-usability@kde.org kde-i18n@kde.org and kde-doc-english@kde.org didn't
get
copied the first time I wrote so you are receiving a (small) update over
something you never saw before. This proposal does not involve translation,
but documentation. I didn't know if I should send it to kde-i18n@kde.org (to
reach all documenters) or kde-doc-english@kde.org (is it English issues
specific?), so I sent to both.

The main idea is to create a community based quality team of non developers,
that would focus on the whole of individual modules of applications, working
orthogonally to developers, documenters, users and testers, instead of the
specific of the whole. In other words think of acting upon the whole of
Kontact instead of acting upon the whatsthis of KDE project. The key idea is
attracting people in a way thats both interesting to them and more useful to
KDE project.This would be the basis of a community oriented (instead of
company oriented) effort of improving this experience. We have a wonderfull
community, kde-look.org, KDE wiki and all the translating teams are strong
evidence of this.

For those who already read it, I only changed the naming from KDE Usability
Maintainers Team to KDE Janitors Team and the Abstract part, to include some
thoughts about QA. I really think that we should find a sexier name than
"janitors". But that name describes better the idea of their function than
usability maintainers.

--- --- ---
KDE Janitors Team Proposal Draft 0.2
Expect grammar errors.

I Abstract

The objective of this proposal is improve KDE by organizing the efforts of
design, user interface and documentation as a result of increase in the
participation of non programmers community in KDE. To reach this goal, no
changes in the KDE traditional decision process are needed. The idea is to
create the role of janitors (note for review: is it a good name? Janitors?
Keepers? Ideas?) for a given library, module or application, who would
organize information and make efforts to improve the evolution of the
projects. (In this document, project will mean library, module or
application, not the KDE project, that I will call KDE).

I was questioned if this could evolve to help building a quality assurance
program, but I am not sure about it, as I don't know if we can maintain the
interest for the volunteers in this very formal process, and I don't even
know if the team a can be usefull in a QA program. A QA program involves the
formulation of the standards and test requirements the software has to meet
(specification), the methods to test the conformance with the specification
(test cases and test suites) and the validation of the results. It is an
extensively documented and technical process. So this is not the focus of
the
proposal. But if someone thinks there is a usefull way to link the two, I
would be glad to know.

II Introduction

The role of product manager in a commercial organization is to integrate
efforts from different areas to reach a given objective. In KDE, this role
is
loosely played by the project maintainer. There are several areas involved
in
the success of the project, and a given developer or contributor can be
proficient in one or more areas:
- Programming (implementation and design)
- New features
- Bugs (related: bug management)
- Documentation
- User Interface Design (implementation and design)
- Artwork
- Design
- Community communication: articles, mailing lists, collaboration with other
projects etc...


Currently, most of the work is done by programmers, but there is a lot time
consuming tasks that could be done by other contributors. Also, each of
these
areas have their own loose structure: programming issues are discussed in
programmers lists, documentation in the docs lists and supervised by the doc
maintainers, user interface and communication even more loosely by some
mailinglists (kde-promo and kde-usability) and by people that feel like
doing
it, without a formal title.

The main difference of a commercial organization and KDE is the lack of
hierarchy: decision making is made generally by consensus or by releasing a
working implementation of a solution to a given problem. The maintainer
holds
no formal power over the others developers, and improvements in the
application are applied in the areas the individual developers want to work,
not always the direction the maintainer wants. And this is good. The correct
tool to improve the direction of the project is not trying to give the
maintainer additional powers. This would drive people away from it, as the
fluid structure is an advantage when your organization is made of
volunteers.
Don't forget that the maintainer is also a volunteer programmer, so he may
leave the project too. He usually is (and should be) very much interested
and
focused in the programming area and general design. So how attract people to
organize information about user interface, to design dialogs and apps, to
write docs, to manage bugs, to create artwork, to communicate with the
community, writing articles and answering mails and bug reports, people that
do not need necessarily to be programmers?

III Proposal: Enter the Janitors Team

The idea is to create a group of people that would assist the maintainers
and
other developers in all areas of the project, but without focus on
programming. There are several tasks that do not require programming, (the
group could also help in the programming area, with help of tools as Qt
Designer). The main idea is to make this group work in an orthogonal manner
with the different areas. Docs, code, articles, bug reports, bugs responses,
user interface suggestions, etc... provided by the group would be handled
the
same way it is today, but the group for each project would have a global
view
for that project. In this sense, they would have the same orthogonal role as
the product managers in companies, so they would share this task with
maintainers and other developers.

They would decide where to work based on their decision about which areas
need
more effort, but their influence in the work of the programmers will be
based
on the quality of the arguments, information and research they provide.

III a Benefits to the Contributor Experience

This is a volunteer project. A proposal will only gather marginal
(additional)
support between contributors if they increase contributors' satisfaction.

Benefits of this proposal to the contributor experience inside KDE include:
- Focus on a single project increase social experience: you get to know the
developers and contributors that work on that project.
- Focus on a single project define clearer objectives: There is less chances
that a potential candidate would be lost for not knowing where to start.
- Focus on a single project the learning time until productive: there is a
lot
to learn in KDE development. Hoe to build a compiling environment, compiling
from sources, the rules of communicating in mailing lists, the Qt tools for
ui designing, user interface books, etc... But the most important thing is
to
know the project very well, and its competitors too, so you can comment on
ui
issues, write docs, answer users mails and bug reports. It is very difficult
to know the whole KDE project in detail.
- Having a defined role increases the sense of being part of the community:
making explicit that someone is part of the community is positive to create
the bonds to keep people inside. Giving the most active contributors a
@kde.org mail account, CVS access and relevance in the discussion may help
too.

III b Benefits to KDE

- Announcing the need for more janitors may attract new contributors: with a
more formal role, we would have guides (I can write them) on what to do, how
to do the job. This way, it would be easier for someone to know what they
will have to do and join.
- The proposition may help to keep the existing ones, for the reasons stated
above.
- Improvements in non programming areas: more volunteers will result in a
big
improvement in areas like documentation, user interface, support for users
and public relations.
- Workgroups with focus may help to level the quality of the docs and ui of
different applications.
- Organize and leverage groups like kde-look.org and kde wiki sites into
working inside the KDE project.

VI Required Steps to Implement the Proposal

- Write guidelines for the janitors 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.
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.
b) General explanation of the committing process: where to send docs,
patches, articles, artwork, etc...
c) General information about writing docs: guidelines, Aaron Seigo's
article about whatsthis, etc..
d) 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.
e) 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.
f) 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.
g) More stuff I can't think of.

- Announce it widely: KDE has a huge user base: we should try all channels,
not only the dot.

- Defining formally the goals of the KDE and who we are trying to reach my
help to design the user interface, help, articles and as a logic tool in
discussions. This way, focus will not be lost, and instead of having several
flame wars in every bug, we would have only one. I think that to write this
document may be a pre-condition.
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]