In an ideal world…

… 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.

Be Sociable, Share!

flattr this!

This entry was posted in Amarok, Free Software, KDE and tagged , , , , , , . Bookmark the permalink.

7 Responses to In an ideal world…

  1. ethana2 says:

    If we had half as many projects, the ones that we have would have twice the resources. If it weren’t for GNU Hurd, CoreBoot would probably run on laptops by now (Hey, let’s make a redundant Free kernel while everyone still suffers with their proprietary BIOS!). If everyone and their mom wasn’t making their own distro, Application X, Y, and Z would probably have Ubuntu packages made at this point.

    We’ve forked ourselves out of an ideal world that we HAVE the resources to maintain.

    • myriam says:

      Hey, I am not talking about distributions, but about KDE and the software in and around it. So this is about upstream work, not downstream :)

    • Ped7g says:

      I don’t agree completely with you.
      Mind you, the developers and other participants are humans, with their tastes and moods. If you take a developer out from Hurd and put it down into (random pick from your favorite projects), you may end with additional manpower or with somebody mean just criticizing and leaving next week.

      Also people creating distributions, while very capable in this, may be not that skilled as application developers.

      So your idea of having half of projects to double the speed of development is purely theoretical. In reality I’m afraid the development speed of many projects would remain almost unchanged, except those in other half, which would be dead definitely.
      Also I don’t think current problems of FOSS SW are result of underpowered teams. I think the current FOSS status very precisely depicts what is important for majority of users. You may feel the free BIOS and more stable core is more important (at least *I* would like that more then another wobbling window effect), but IMHO the way how current linux distributions looks is very accurate picture of what the community truly wants. Some people will have to swallow a bitter pill, but generally it’s marvelous time, when you can belong to a marvelous community of FOSS people, even if you personally hope for something a little bit different.

  2. Vadim P. says:

    Would be glad to help but I don’t use Amarok, and my free time is already overstreched on other FOSS projects. Default Ubuntus music player works great for me.

  3. Justin Kirby says:

    Great post! KDE definitely needs more triagers so they can spend their time fixing bugs instead of sifting through reports. This is also a great way for newer folks to get involved in their favorite projects. :)

  4. Thanks for the shout-out, Myriam! I’m hoping that users step up and become contributors. Sure, we can always use more coders, but so much else is needed — and we can all do something.

    To me, that’s the heart of free and open software.

  5. Crashit says:

    Should be easy to solve those duplicate bugreports. Just make some bugtracking system on the users computer that works :) If my Amarok crashes, I should only have to click once or twice to report the bug. When the bug is filed, it should automatically track bugreports of the same kind and categorise it.

    Such a program should solve the duplicate bugreports and make bugtracking and solving a lot easier…