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.
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.
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:
kill -SIGSEGV <process id>the process to get a stack trace.
git logor on quickgit.kde.org.
Browser (Konqueror) bugs are usually very easy to check and there are lots of them:
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