Bugsquad/Howto - KDE Community Wiki

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. KDE's Bugzilla instance is reachable via bugs.kde.org.

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 gives you insight about the most needed features and most pernicious bugs, allowing you to point them out. This allows developers to spend more time on actually fixing bugs and to add new features instead of just managing bug reports.

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.

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, or close them if they cannot be verified.

You need a current installation in order to be able to test if a bug is still valid. You should test with the latest development version of a product, which is on the master branch for most KDE modules. This guide helps you to build these development versions.

When building KDE modules for bug triaging purposes, make sure to include debug symbols, assertions and the like. Since KDE modules usually use the CMake build system, this can be achieved by setting the CMake build type to Debug (or, in rare cases, FullDebug). A program compiled with debug information is bigger and runs slower, but provides 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 provides you with a dialog to report the crash. This dialog can be used to easily extract a stack trace that led to crash, and crashes reported using this dialog always include the corresponding stack trace.

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 your way around the application and have enough experience with bugzilla, it is time to ask for permissions. Ideally, you would issue a KDE SysAdmin ticket for that, and include some links to bugs you commented on to demonstrate that you know what you are doing. Alternatively, you can ask in #kde-sysadmin on freenode. 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. Most of the tasks 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. stack trace, 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 CONFIRMED.
If a program hangs, you can kill -SIGSEGV <process id> the process to get a stack trace.
Check if the report is filed into the correct product and component category. KDE is very modular, and massively reuses code. It can be hard at times even for the developers to detect which component a bug is in, 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, you may assign a bug report to him/her directly. Active developers can regularly be found by looking at the version control log, usually via git log or on quickgit.kde.org.
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.

You probably want to read the Bugzilla User Guide, which also documents the Life Cycle of a Bug in a comprehensive diagram. Custom fields of KDE's Bugzilla instance are described here.

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. Feature requests titled "Feature request" don't help when glancing over the report list. If a patch is provided, add [patch] to the title.

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