Transcript of talk: "The future and promise of Quality Teams in KDE"
KDE Contributor and Developer Conference
Notes taken by: Jonathan Riddell (these are not official material)
More information on the talk can be found hereThe Quality Team project started this year by Carlos Leonhard Woelz.
The motivation
Currently developers talk to developers through mailing lists, IRC etc; users talk to users (productively) on sites like KDE-Look and KDE-Apps; users talk to developers via news sites (to some extent) and bugzilla. Developers talk to users via blogs (which has been improved with kdedevelopers.org and planetkde) and through the press. This isn't ideal.
Scenario 1: user wants a feature and enters it into the beasties database. The developer reports asking for technical details. User then becomes confused and gives up. Maybe the developer implements something, but it's not what the user wants, and so the user starts spamming web sites with the bug report looking for votes and flaming developers.
Scenario 2: user wants to help KDE project, learns a little C++ but doesn't know where to help, asks on mailing lists and looks at beastie database for jobs. User realises they aren't a good coder so does documentation, moves around until finds place in project. There is psychological barrier between being user and developer.
Scenario 3: developer wants a new splash screen, e-mails some artists and may or may not get a good splash screen. If he does, it's probably a lot of work.
The solution
Quality Teams sit between developers and users (in fact they overlap since developers and users can be in the quality teams). Can help with beastie database management, user interface and general testing, documentation, communication and promotion and anything else they can do.
Scenario 1 again, user knows some C++, e-mails kde-quality list, gets ideas for what to do, does them with help from Quality Team memebrs.
Scenario 2: developer wants a new splash screen, asks quality team, quality team create a competition on kde-look and promote it to get a result.
Quality teams improve the whole of KDE by helping users and developers.
They have a kde-quality mailing list, but discussions often move onto specific list e.g. kde-multimedia to prevent duplication. Quality Team wiki pages, help new contributers into the world of KDE. Developers and users can also just ask for help, this is welcome.
Developers can benefit from Quality Teams and Quality Teams need developers. So Tom is asking for developers to get more involved in working with Quality Teams. Things for developers to do:
- Be aware of Quality Teams and be in contact with Quality Teams
- Maintain task lists
- actively recruit people e.g. in your .sig or in news site comments
- lurk on kde-quality mailing list
- ask for help, kde-quality will do better the more that people throw at it
Quality teams can break down the divide between users and developers, give new opportunities and improve KDE.
