Contribute/Bugsquad/Howto

The main communication tool between developers and users, and the main quality tool is the KDE bugs and wishes database. The database is implemented using the Bugzilla tool for tracking bugs and wishes, developed initially for the Mozilla web browser. [1] is the the web front end implementation of KDE's Bugzilla, and the main place to go when managing bugs, but there are other front ends: the KBugBuster, from the kdesdk module and the e-mail interface, used to add comments, change bugs status, etc...

Many bug reports are filed daily, especially after releases. There are too many to be handled by the developers, so the amount of open reports increases over time. Additionally old bug reports have to be revisited regularly to see if they still apply to the current version. Reviewing the bugs database also give you insight about the most needed features and most pernicious bugs, allowing you to point them, and the developers to actually fix bugs or spend time to add new features to KDE, instead of managing bugs.

Always direct users to the KDE bug tracker system to discuss bugs and wishes, because this way issues will not be forgotten. If the point is a bit more polemic, it is sensible to start a discussion in the application mailing list or in KDE usability mailing list, but instruct them to start by filing the bug, because by searching for similar bugs or wishes they may find answers or insight.

Before Starting

To start, open an account on bugs.kde.org if you don't have one. The database records not only the bugs and wishes status, but also related discussions, screenshots, patches, etc.. turning it to a very complete source of information. Please try the following pages at bugs.kde.org, to get used to KDE bugzilla capabilities. The KBugBugster is also useful, but less flexible.

At the beginning, you will only be able to comment on bug reports which are not your own. Only after acquiring more knowledge on the application and on KDE Bugzilla system, you may ask for rights to confirm bug reports and close non verifiable ones.

You need a current KDE installation in order to be able to test if a bug is still uptodate. This means you should either test with 'trunk', that is the latest development-version of KDE, or the latest branch of KDE. See http://techbase.kde.org/Getting_Started/Build/KDE4

Also it is important to have a KDE version compiled with debug information. KDE binaries compiled with debug information are bigger and run slower, but provide invaluable information to the developers when applications crash, as they are able to locate where in the source code it crashed, and sometimes even why. Whenever an application crashes, the KDE crash handler appears. You can now retrieve the backtrace information to add to a bugreport.

Managing Reports

The main tool for bug triage is knowledge of your application. You will learn that you don't need to be a developer to have a good understanding of it: reading bug reports and comments about them, writing documentation or working with the application's user interface will do the trick.

You should always start by stating your opinion in the bug reports and letting the developers take the appropriate action. If you feel you are ready to manage bugs effectively, know well the application and have a bit experience with bugzilla, it is time to ask for permissions. The Quality Team mailinglist, the KDE system administrator, or the mailinglist of the application you are working with, are the right places to ask for it. The developers will probably be happy to have someone working with them, and in the end of the day it is your own reputation as a good contributor that is in the line, as developers will still watch what you are doing. Some of the task below require these permissions.

A good way to start is checking if bugs are still valid:

Believe the reporter: if you cannot reproduce a new bug, first ask for more context information, then think about closing it or asking to close it.
The bug may be triggered by a combination of factors, or the bug may be fixed in the main branch, but not in the stable branch (if so, ask in the bug report for a backport. If it is not doable, the developers will say so).
Add any additional information you can give, e.g. backtrace, additional observations, how to (better) reproduce the faulty behavior or simply add with which day's version the bug still appears.
If you can reproduce an UNCONFIRMED bug, please write that in the bugreport and change its status to NEW.
If a program hangs, you can "kill -SIGSEGV Processid" the process to get a backtrace.
Check if the report is filed into the correct product and component category too. KDE is a very modular, and massively reuse code, and sometimes is hard even for the developers to detect in which component the bug is, so be careful. If the report is not already assigned to some other developer than the current component owner, make sure to select the "Reassign bug to owner of selected component" when moving a report. If a report is filed into a category where there is no single maintainer/active developer and you know which developer is responsible or works on the code (a look into the source or reading kde-cvs mailing list can help), you may assign a bug report to him/her directly.
Check if a report describes an error already described in another closed or open report: Resolve it as DUPLICATE with reference to the prior report.
Check if the same report was submitted more than one time. Please close the identical bug (the one with the highest number) as INVALID and not as DUPLICATE because otherwise they show up wrongly in the most frequently reported bugs statistics.

Browser (Konqueror) bugs are usually very easy to check and there are lots of them:

Add "(regression)" to the title if the page was correctly rendered in a previous stable release.
It's a good idea to put the site into the title where an error was encountered to ease duplicate spotting.
A parallel installation of a Gecko-based browser and Opera can give you an idea how a web page probably should look like.
Try to generate a stripped down testcase of a faulty rendered webpage. Add "(testcase)" to the title if a testcase is attached to the bug report.
If a webpage doesn't exist any longer or was obviously rewritten and there was no testcase provided, close the report as WONTFIX.
If the reporter or a comment mentions that a page works fine in Safari, it can help the developers to note that in the title too.

Check if the severity is appropriate, but if you don't agree, state so in the bugreport. Let the maintainer change the severity, as it is used by them to remind to fix crucial issues.

Check if the title contains a good summary, e.g. feature requests titled "Feature wanted" don't help when glancing over the report list. If a patch is provided add "(patch)" to the title.

Note: Don't use the "Change Several Bugs at Once" feature for moving reports. There is a bug in Bugzilla which confirms every reports which gets moved.

The KDE Bugsquad coordinates bug triage efforts as well as organising regular bug-days where many people work together to clearup all the bugs for a particular program. Bug-days are an excellent oppurtunity for making your first steps in contributing to KDE, and there are always plenty of experienced bug-busters on hand to help you with any difficulties you may have. For more information, see the Bugsquad Techbase pages

This article originally from Carlos Leonhard Woelz -- http://websvn.kde.org/trunk/www/sites/quality/develop/howto/howtobugs.php?revision=1044461&view=markup&pathrev=1100000