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.  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.
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.
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:
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, 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