Policies/Draft/The Power Of The Doer: Difference between revisions
Fulldecent (talk | contribs) (copied content from http://quality.kde.org/develop/policies/) |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
THIS IS NOT CURRENTLY AN OFFICIAL KDE POLICY | |||
Most of KDE contributors are volunteers, either programmers, artists, writers or translators. A traditional organization of hierarchy in this case is difficult to maintain and inefficient. But there are some rules and principles that help coordinating the efforts, and it is fundamental to know them. | Most of KDE contributors are volunteers, either programmers, artists, writers or translators. A traditional organization of hierarchy in this case is difficult to maintain and inefficient. But there are some rules and principles that help coordinating the efforts, and it is fundamental to know them. | ||
| Line 23: | Line 25: | ||
decided to be the right path, it does not mean it will be implemented: someone | decided to be the right path, it does not mean it will be implemented: someone | ||
must have the time and will to implement it. | must have the time and will to implement it. | ||
(This content originally by Carlos Woelz from http://websvn.kde.org/trunk/www/areas/quality/develop/policies/index.php?annotate=286645&pathrev=286645) | |||
Latest revision as of 15:26, 26 March 2011
THIS IS NOT CURRENTLY AN OFFICIAL KDE POLICY
Most of KDE contributors are volunteers, either programmers, artists, writers or translators. A traditional organization of hierarchy in this case is difficult to maintain and inefficient. But there are some rules and principles that help coordinating the efforts, and it is fundamental to know them.
The Power Of The Doer
In a volunteer project, the way to make something happen is present a concrete solution, better yet if followed with an implementation. For example, pointing out that KDE context help for dialogs is incomplete will not be useful, people already know that. Writing context help for dialogs and sending it to the maintainer is the only practical way to change this reality. There is also a lot of room for different approaches in the implementation, as the maintainer is likely to accept something he does not consider the best possible solution if he judges it is an improvement. Programming issues are decided by programmers, documentation issues are solved by documentation writers and so on.
The Maintainer Role And The Decision Process
The maintainer is the guy who formally takes responsibility for an application or library. But it does not mean that he takes all decisions. For controversial issues, the general decision is made by voting. To have a voice in the voting process, it is necessary to be a current contributor, with relevant past contributions. Anyone can try to influence the decision process by presenting thoughtful arguments and evidence. And even when something is decided to be the right path, it does not mean it will be implemented: someone must have the time and will to implement it.
(This content originally by Carlos Woelz from http://websvn.kde.org/trunk/www/areas/quality/develop/policies/index.php?annotate=286645&pathrev=286645)