Contribute/Bugsquad/Guide To BugTriaging

< Contribute‎ | Bugsquad
Revision as of 22:39, 1 April 2010 by DarioAndres (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Initial version by Dario Andres (2010-03). Corrections by Lydia Pintscher



All this guide is based on my own experience (approximately 2 years) on the KDE bug tracker.

It may not work for you ;)

General Considerations

  • Be polite: when you need to request information or feedback be clear and polite, and you will get more information in less time. 
Often Bugzilla is a place which involves discussions (about implementations, or even about contributors). Try to be concise and polite, respecting the others position while describing your own.
  • Don't try to do too many things at the same time; otherwise you will end up with a headache.

If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: Quick Introduction to Bugzilla

About getting permissions to work in the bug tracker

Manpower is always needed in a bug tracker, but as any action taken on it may be potentially destructive to other people's work; or it may end up messing things up (and consuming the developers' or other triager's time) the tracker requires special permissions to perform changes in bug reports.

If you want to work in the bug tracker you need to prove that you know what you are doing.

Initially you will ask for support on #kde-bugs (on IRC) and add comments in the bug report (so other people will see and check them, perform the needed actions, and evaluate your work)

adding comments in the bug report is allowed for every user

Getting Started: Find what to work on (Different Approaches)

Workflow of the bug triaging activity

Handling reports: What to do with a bug report

Trying to reproduce the bugs

Getting bug triaging support



More Information

KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal