From kde-usability Fri Dec 19 22:54:41 2003 From: Carlos Leonhard Woelz Date: Fri, 19 Dec 2003 22:54:41 +0000 To: kde-usability Subject: KDE Janitors (QA?) Proposal X-MARC-Message: https://marc.info/?l=kde-usability&m=107187409020725 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