… every Free Software project should not only have developers, but also
- graphical artists
- usability experts
- user support specialists
- documentation writers/translators
- software translators
- bug triagers
- marketing ninjas
- community managers
- release managers
- website and wiki maintainers
- unlimited funds…
Amarok is very lucky to have most of those. No, not the unlimited funds, sadly, thats one of the reasons why we ask our dear users and Amarok lovers to support us with donations, it allows us for example to maintain our server, which in turn can host other Free Software projects of the KDE family like Konversation.
Linda and Valorie have started to write the handbook for Amarok 2.2.2, and Valorie is currently looking for skilled wiki writers and maintainers, too.
I am more active in doing user support and act as a bug triager for Amarok, and occasionally also other KDE projects like Phonon. This all started on a rainy Sunday afternoon when I tried to get rid of some of the numerous duplicate bug reports and wishes and I got hooked on it. Some 12 months later I have closed 1885+ bugs and triaged thousands of others: Amarok went from 2.0 to 2.2.2 and got 2864 new bug reports and wishes in this time, of which 3071 could be closed. An average 5-10% only were unique bugs, all the rest were either duplicates, invalid, already solved or reported against the now unmaintained Amarok 1.4.x. Some were also reported against Amarok by error and had to be reassigned to another project.
Bug reports and wishes are something that definitely needs triaging, since many reports have flaws. This can be
- an incomplete or a too complicated description, sometimes not even in English
- missing elements: version number, distribution, what were they doing when the bug occured
- in case of crashes: incomplete backtraces
- more than one item per report, which makes it too difficult to follow
- duplicates
- already implemented features or corrected code
- Invalid reports
All of these flaws are quite common, it is rather rare to get bug reports that can be used “as is” by the developers. And that is my point: bug triaging is not a developer task. Developers develop code, they should not have to loose their time running after users for more information about a bug or a wish. Unfortunately most of the projects don’t have their own triagers and rely on the KDE bugsquad to do this task, which is not that easy and something that needs to be addressed:
While much of the triaging can be done by people not involved in a particular project, it gets difficult when the triager doesn’t know the application. IMHO s/he should at least be a regular user of the application and ideally also run the developer version from GIT or SVN. This is not as complicated as it sounds, most of the projects have step-by-step instructions on how to build from trunk. If it is one single application the triager is interested in, s/he can build it locally in the home directory, which can be easily removed if needed. But it is of course important that the triager is in direct contact with the developers, be this only to be able to get feedback from them if necessary.
I encourage all larger projects to recruit dedicated triagers. This has more than one advantage:
- it takes away an important workload and the developers can concentrate on their primary task
- dedicated triagers know the application and can judge much better what is needed to make a report useful than somebody who occasionally triages here and there
- it adds strength to the team, and dont’ forget, sometimes triagers become developers 🙂 (not me, there are already too many bad coders in this world … )
- id adds efficiency to your development cycle, and you find your way around in the bugs list since all incomplete bugs are gone
Now how do we recruit triagers? This can be done by encouraging advanced users to give a hand from time to time, I can assure you, bug triaging can get addictive 🙂
But there is a much easier way: through the BugWeeks dedicated to bug triaging in the KDE Forum. The first BugWeek has just ended, set up and lead by Darío Andrés, our “Bugs Hero” who had the initial idea and set up all the course. We plan to hold two BugWeeks per month and encourage everybody to participate and make the number of untriaged bugs much, much smaller! Also, a BugWeek on the forum has the advantage of being easier to run than a BugDay, where people need to be online at the same time and share a wiki.
On another hand I would like to write about a particular form of invalid bug reports: those from poisonous people. Every project has sometimes to face people submitting bug reports and wishes in non-objective ways . The bug may exist, but the way these particular reporters report it and comment on it is poisonous, subjective to the extreme and sometimes quite insulting. A non-objective report is not something one can act upon in another way but by marking it as Invalid if the reporter doesn’t change their tone. To avoid loosing the important information, IMHO the triager should make a new report with the important information, but close the original one.
I have done this twice already and it worked out quite well, so I think this is really worth a try.
My reason for doing this is clear: useless reports by these people, insulting and personal attacks are discouraging and demotivating for the developers. It can in the worst case lead to developers leaving a project because of this. The triagers have a unique possibility to avoid these insults to reach the developers in filtering those. Of course this can be dangerous for the triagers, too, as themselves can get wary of such posts.
We here should all think and take action to not let this happen and make use of the wonderfully motivating and supportive network we have which is KDE: talk about around you and let the magic work. Don’t keep it in your mind alone or in your developer channel or mailing list or bug report, talk to your team, to your friends, to the bugsquad and of course the Community Working Group. And don’t forget the two last paragraphs of the KDE Code of Conduct: Support Others in the Community and Get Support from Others in the Community.
