Difference between revisions of "Contribute/Bugsquad"

Jump to: navigation, search
(Link to a new article)
(Articles: better title :/)
Line 19: Line 19:
[[/How to get proper backtraces|How to get proper backtraces]]
[[/How to create useful crash reports|How to create useful crash reports]]
==External links==
==External links==
*[http://bugs.kde.org/ Bug tracker]
*[http://bugs.kde.org/ Bug tracker]

Revision as of 14:45, 22 May 2007

The Bugsquad tries to keep track of bugs in KDE software and make sure that valid bugs are noticed by developers. You do not need any programming knowledge to be in the Bugsquad; it is simply a great way to give practical support to the KDE community if you are just starting out (or still relatively early) along the Programming Learning Curve (PLC).


How to help

Read the guide and join us for one of our bug weekends. We meet in IRC in channel #kde-bugs on irc.freenode.org. You can get started have your questions answered there. Even outside of weekends someone in IRC will usually be able to help you.

A summary of the Bugsquad guide is provided below to give you a quick idea of how you can help:

  • Confirming bugs. Bugs with the UNCONFIRMED status should get the NEW status once someone else is able to reproduce the bug reliably.
  • Finding bug duplicates. Many bugs entered into Bugzilla are duplicates of other bugs. Sometimes it's hard to recognize these as duplicates but multiple people checking can make the duplicates bubble to the top of the pile. The following remarks may help you identifying them:
    • Using the Similar Bugs link to look if there are duplicates.
    • In the case of crashes, use the link below the comment field to look for crash reports with the same backtrace. The backtrace must be in the body of the report in order to look for similar reports. This tool does not look in attachments with backtraces.
  • Close bugs which insufficient information and which are open for quite a long time (e.g. reporter does not respond on a need-more-info request). Usually a timeout of one month or more is considered to be an "information timeout".
  • Categorize bugs into the right components. Many bug reports can be further categorized to components; for example Konqueror reports can be assigned to khtml and kfm components.
  • Labelling bugs which contain testcases as such in the title. Ideally, testcases contain the minimal amount of code (HTML, scripts, C++ etc.) necessary to reproduce a bug.

Bugs to be done

A temporary place we will use for bugs that need additional attention is the Bugs to be done page.


How to create useful crash reports

External links

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