Author: Stephen Feller
Elected to the TWG were former release coordinator David Faure; Dirk Mueller, who has contributed heavily to KDE system administration and infrastructure; Canadian and North American press contact George Staikos; KDE Accessibility founder Gunnar Schmidt; Lubos Lunak, who maintains several projects within KDE; current release coordinator Stephan Kulow; and KDElibs contributor Thiago Macieira.
The seven developers will serve on the TWG for six months, giving KDE e.V. an opportunity to evaluate the group’s effectiveness. KDE e.V., run by a board of directors and members of the KDE developer community, is the non-profit organization responsible for the projects’ financial and legal interests, as well as making major decisions for it.
The TWG is the second working group elected by members of the KDE e.V., after one for marketing in November.
According to the TWG charter approved in January, the group’s responsibilities are to set an official release schedule; define what will be included in official releases; manage the coordination of releases; oversee the applications and libraries included in source code modules; make decisions about external or inter-module software dependencies; maintain technical infrastructure of KDE; and offer technical guidance to the entire project. The charter requires group members to coordinate with other working groups and individual development teams when making decisions in these areas.
Without an “accepted way to draw conclusions,” threads on discussion boards often simply collect opinions rather than arrive at decisions to be acted on, says Cornelius Schumacher, vice president of KDE e.V.’s board of directors. He offered as examples discussions on the inclusion or removal of applications from the core KDE modules, adoption of external libraries, and release plans.
“With the Technical Working Group, we now have an instrument to help with making these kinds of decisions,” Schumacher says. “This is based on the legitimization of being elected by the core members of the project.”
In a post at KDE Dot News, KDE developer Alexander Neundorf writes that he is in agreement with Schumacher that the election results don’t change much as far as how the project works or who is making overall decisions for it. “These are the people which we trusted already before, and this was now simply formally confirmed by the election,” he writes.
Schumacher says the elected group will keep the project moving, and its most important task right now is laying out a roadmap for the release of KDE 4.
Like many open source projects, KDE has followed the “he who does the work decides” rule, says Lunak. But with more people contributing to more projects within KDE, the size of the project demands that somebody choose what to include and when. He adds, however, that the project’s longtime development system should remain largely the same, with the TWG “acting more like a group of elders [who] respect the community, rather than dictators.”
Protecting and helping to foster the bazaar-like development path the project has had since its beginning is a priority for the group, says Staikos. He says he doesn’t expect the TWG to dictate development or force developers to work on specific projects, but he still wants to see how the group’s efforts to keep KDE code top-notch and on schedule play out over the next six months.
“I could imagine a case where developers are unable to make decisions without consulting the TWG,” Staikos says. “I can also imagine a case where the TWG forces code changes on developers because they believe that the code done by a developer is sub-standard. This is very subjective and could lead to problems on both a technical and social level on the project. I hope this does not happen.”
Quality control and conflict resolution dominated discussion about the working group at KDE’s aKademy 2005, an annual meeting where KDE developers discuss and work on the project. Mueller says the TWG should help ease concerns about both areas. The group as a contact point, he says, will keep developers from fighting issues out and never coming to a solution — the sort of thing that could hamper the progress and effectiveness of work on KDE.
“That doesn’t mean that the TWG will overrule the KDE projects’ community opinion,” Mueller says. “It will just make sure that queued decisions are being discussed and made by community consensus, rather than being forgotten or ending in a flamebait where the one who shouts the loudest wins.”
Until the group was created, releases were planned by a release coordinator, and quality control of code added to the KDE repositories was left mostly to the developers working on it. The TWG isn’t expected to direct development, but rather help by organizing and guiding developers. The fear of some sort of bureaucracy emerging from an elected group at the top, however, does exist.
Staikos, like others on the TWG, says he believes the group can guide and coordinate while not making decisions for people. As the groups’ trial run begins, he says the only thing that is clear at the outset is that it needs to stay away from telling developers what to do.
By removing some of the decision-making from individual developers’ shoulders and placing it in the hands of a group elected by them, Schumacher says KDE will be able to better move forward because of better coordination of contributors’ efforts. And with an ever-growing group of developers making contributions, he says this is what KDE needs to maintain the standards that contributors and users have for it.
“The KDE project is constantly growing,” Schumacher says, “and we felt that we needed an additional instrument to keep the development process running smoothly. In some way, we created the group to cope with our own success.”
Category:
- Open Source
