KDE Usability Maintainers Proposal

[Carlos Leonhard Woelz]

Hi.

This is a small proposal I wrote in order to increase KDE user experience, and 
counter GNOME's marketing about HIG and usability. I understand usability as  
the general user experience, not only ui design. 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. This proposal does not 
involve translation, but documentation. I didn't know if I should send it to 
kde-i18n at kde.org or kde-doc-english at kde.org, so I sent to both.

--- --- ---
KDE Usability Maintainers Team Proposal Draft 0.1
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 usability maintainers (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).

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...
Usability is defined as the general experience of the user, including all the 
above areas, not only ui design.

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 Usability Maintainers 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 usability maintainers 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 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.
	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.

V Conclusion

That's it! I hope you find it valuable. At least we can make a good case study 
if it fails ;). But I think the arguments are strong. My main point to 
support this is: it is worth trying! I can handle writing quite a bit of this 
stuff. So give me an OK, and I will carry this on. I am also candidate for a 
maintainer position ;).

Cheers,

Carlos Woelz