KDE Quality Team
KDE and Free Software General Policies
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 quality team works in close cooperation with the developers and the maintainer. 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.
More general issues, or issues the developers of the applications have difficulties handing themselves are handled by the KDE core developers. To be appointed a KDE core developer you need a history of outstanding contributions to the project.
The KDE Release Schedule
The KDE stable releases are not the place where the development is done, because new features mean new bugs too. For this reason, new functionality is reserved for the unstable code base (HEAD branch), but even there, sometimes you cannot add new features. To be able to make a release of KDE a lot of cooperation between all contributors is needed. To stabilize the code base so that bugs can be tracked and translations can be made, at some point it is necessary to impose a restriction on new features and strings (words used by the user interface that have to be translated). To coordinate this effort, a release maintainer is elected and a release schedule is made. To respect the schedule is a KDE contributor duty.
[ Edit ]
