[dot] KDE Bug Tracker Hits Report 100,000

[Dot Stories]

URL: http://dot.kde.org/1109112982/

From: Philip Rodrigues <phil at kde.org>
Dept: too-many-to-count-on-your-fingers
Date: Tuesday 22/Feb/2005, @23:56

 KDE Bug Tracker Hits Report 100,000
====================================

   With bug number 100,000 reported, the hard-working KDE bug tracking
system [http://bugs.kde.org] reached a milestone today. However, not
everyone knows what goes on behind the scenes and how to help. In this
article, I take a short look at using the bug reporting system, and how
you can help KDE improve.

     To get such a large number of reports from users and developers of
the software takes some time. However, reports have been entering the
system since the early days of KDE back at the start of 1999. With such
an impressive amount of data in the bug database, it's worth taking a
look at how it's all organized and kept running smoothly, and what you
can do to help.
 More than you might think
     The KDE bug tracker doesn't just contain reports of crashes and
misfeatures in applications, but plenty of other information. If there's
a feature you'd like to see in KDE which others would find useful, you
can file a 'wishlist' bug requesting it. We'll look at the best way to
report wishlist requests shortly, but just keep this in mind for the
moment. And KDE isn't just code! You can also file a bug against
documentation if you find a problem with it - just use the docs product.
And the polished look of KDE is important too: you can report problems
with icons, wallpapers or splash screens in the artwork category.
 Getting involved
     With dozens of bugs reported each day (as I write this, the system
tells me that 105 bugs were reported today alone), maintaining and
organising all that information is no small task. Although many KDE
developers put a lot of time into dealing with bugs, it's not always the
most efficient way for them to spend their limited time. And that's
where you can help. Bug triage is a simple but effective way to get
involved with KDE. The definitive guide is the KDE Quality Team bug
triage howto [http://quality.kde.org/develop/howto/howtobugs.php], but
here are some tips to get you started:

    * Choose an application (or applications!) that you like and are
      familiar with, and watch bugs for that application. That way, you
      can judge more easily whether the bug is valid, and you'll
      rapidly become familiar with the bugs that are already reported.
    * Running a CVS HEAD or stable branch (KDE_x_x_BRANCH) version of
      KDE will allow you to check whether bugs have been fixed in the
      development version of KDE. It's a worthwhile payoff for the time
      it takes to compile a CVS version.
    * Consider working on bug reports for the Konqueror HTML renderer
      (KHTML). They're quite easy to test, and the quality team howto
      gives some good tips on how to produce test cases and so on.

     If you'd like to help with bug triage, but aren't sure where to
start, drop the KDE Quality Team a line at kde-quality at kde.org
[kde-quality at kde.org]. Remember, it doesn't necessarily take a lot of
your time, but can really help KDE to improve.
 Getting the most out of the system
     Despite the hard work of all the KDE developers, bugs sometimes do
hamper your work in KDE. But, as a user, you're in a position to be able
to do something about it. The first line of attack is to file a bug
report on bugs.kde.org [http://bugs.kde.org]. There are some easy ways
to make sure that your bug report is as useful as possible. Following
them makes life easier for the developer reading the report, and makes
it more likely that the bug will be fixed, so everyone wins.

     The definitive guide to effective bug reporting is by Simon Tatham,
prosaically called How to Report Bugs Effectively
[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html]. I won't repeat
everything he says, but just note some things that are particularly
relevant to KDE.

    * Check carefully that the bug hasn't already been reported.
      Bugzilla has powerful query tools for this, so make sure you use
      them when reporting a bug. If the bug has already been reported,
      read the comments to see if there's anything useful you can add
      (for example 'this bug also occurs in the latest cvs version').
    * Work with the developer, not against him or her. It might
      seem like you're on opposite sides, finding problems in a
      programmer's code, but you have the same aim - fixing the bug.
      Provide any information about your system that the developer asks
      for, and test any workarounds that he or she asks for.
    * If you're filing a wishlist bug, make sure that you're clear
      about what you are requesting. A simple graphic or a mockup of
      what you'd like can sometimes speak louder than words (but put
      the words in too!).

     In conclusion, the KDE bug database is a powerful tool for both
users and developers, and a great way for new contributors to give
something back to the KDE project. With a few simple guidelines, it can
be made the most productive possible, with very little pain. So get
reporting and triaging!