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

List:       kde-usability
Subject:    KDE Janitors (QA?) Proposal
From:       Carlos Leonhard Woelz <carloswoelz () imap-mail ! com>
Date:       2003-12-19 22:54:41
[Download RAW message or body]

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

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