Difference between revisions of "Contribute/Bugsquad"

Jump to: navigation, search
(How to help)
(copyediting/etc)
Line 1: Line 1:
 
{{Tip|
 
{{Tip|
Thanks to all who took part on 6th April. The date of the next bug day will be decided soon.}}
+
Thanks to all who took part on 6th April. The date of the next BugDay will be decided soon.}}
  
The '''Bugsquad''' tries to keep track of bugs in KDE software and make sure that valid bugs are noticed by developers.
+
==What is BugSquad?==
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).
+
 
 +
The '''BugSquad''' keeps track of bugs in KDE software and makes sure that bugs are verified, and helps developers notice valid bugs.
 +
You do not need any programming knowledge to be in the Bugsquad, and it is a great way to give practical support to the KDE community if you are just starting out (or are still relatively early) along the Programming Learning Curve (PLC).
  
 
==Bug Days==
 
==Bug Days==
The date for the next bug day has not yet been decided. However, if you want to start triaging the bugs now, you can go to the [[/BugDays/KonquerorDay2|bug-day page]].
+
The date for the next Bug Day has not yet been decided. However, if you want to start triaging bugs now, you can go to the [[/BugDays/KonquerorDay2|bug-day page]].
 
The results of all past bug days can be found [[/BugDays|here]].
 
The results of all past bug days can be found [[/BugDays|here]].
  
 
==How to help==
 
==How to help==
Read the [[/Guide|guide]] and join us for one of our [[#Bug_Days|bug days]]. 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.
+
Read the [[/Guide|guide]] and join us for one of our [[#Bug_Days|bug days]]. We meet on IRC in channel #kde-bugs on irc.freenode.org. You can easily get started by having your questions answered there. Someone in IRC will usually be able to help you. Although we do sleep sometimes!
 +
 
 +
A summary of the BugSquad guide is provided below to give you a quick idea of how you can help:
  
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.
 
* 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:
 
* 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.
 
** 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.
 
** 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".
+
* Close bugs which have insufficient information and which have been open for a long time (e.g. reporter does not respond to 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.
+
* Categorize bugs into the right components. Many bug reports can be further categorized into 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.
+
* Labeling 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.
 +
* Writing testcases. Very useful and saves developers' time.
  
 
==Getting started==
 
==Getting started==
The sheer number of open issues can be overwhelming at the start. Here are some hints on getting started more smoothly:
+
The sheer number of open bugs can be overwhelming at the start. Here are some hints on getting started more smoothly:
* Look at a single product at a time. For large applications (like e.g. konqueror), you may want to further limit your search to a particular component.
+
* Look at a single product at a time. For large applications (like Konqueror), you may want to further limit your search to a particular component.
* Don't try to find duplicates as the very first thing. Finding duplicates is hard until you have become familiar with the bugs in a component. Start out with UNCONFIRMED bugs as described above. That's valuable work, and a great way to familiarize yourself with the bug database.
+
* Don't try to find duplicates early on. Finding duplicates is hard until you have become familiar with the bugs in a component. Start out with verifying UNCONFIRMED bugs as described above. That's valuable work, and a great way to familiarize yourself with the bug database.  
* Avoid very old bugs with many comments, and also bugs with many votes at the start. This may seem counter-intuitive, but in most cases these bugs are just too hard to deal with when getting started. If they were not hard, they probably would have been taken care of already. Revisit those later.
+
* Avoid very old bugs with many comments, and also bugs with many votes. This may seem counter-intuitive, but in most cases these bugs are hard, have gotten a lot of attention, and are probably on a developer's TODO list already. If it is from an older version of KDE, and there are no recent comments, verify them, make a notation, and move on.
* Don't be afraid to ask the reporter for more info. It's something you can even do without bugzilla permissions. And reporters will generally prefer being asked one question too many, instead of their report never being dealt with.
+
* Don't be afraid to ask the reporter for more info. It's something you can even do without Bugzilla permissions. And reporters will generally prefer being asked one question too many, instead of their report never being dealt with. Just remember to be polite. Ask yourself how you would feel if you got the message you are thinking about sending to a user.
 +
* Look through the rest of our documentation for more information!
  
 
==Articles==
 
==Articles==

Revision as of 08:33, 15 April 2008

Ktip.png
 
Tip
Thanks to all who took part on 6th April. The date of the next BugDay will be decided soon.


Contents

What is BugSquad?

The BugSquad keeps track of bugs in KDE software and makes sure that bugs are verified, and helps developers notice valid bugs. You do not need any programming knowledge to be in the Bugsquad, and it is a great way to give practical support to the KDE community if you are just starting out (or are still relatively early) along the Programming Learning Curve (PLC).

Bug Days

The date for the next Bug Day has not yet been decided. However, if you want to start triaging bugs now, you can go to the bug-day page. The results of all past bug days can be found here.

How to help

Read the guide and join us for one of our bug days. We meet on IRC in channel #kde-bugs on irc.freenode.org. You can easily get started by having your questions answered there. Someone in IRC will usually be able to help you. Although we do sleep sometimes!

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 have insufficient information and which have been open for a long time (e.g. reporter does not respond to 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 into components. For example, Konqueror reports can be assigned to KHTML and kfm components.
  • Labeling 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.
  • Writing testcases. Very useful and saves developers' time.

Getting started

The sheer number of open bugs can be overwhelming at the start. Here are some hints on getting started more smoothly:

  • Look at a single product at a time. For large applications (like Konqueror), you may want to further limit your search to a particular component.
  • Don't try to find duplicates early on. Finding duplicates is hard until you have become familiar with the bugs in a component. Start out with verifying UNCONFIRMED bugs as described above. That's valuable work, and a great way to familiarize yourself with the bug database.
  • Avoid very old bugs with many comments, and also bugs with many votes. This may seem counter-intuitive, but in most cases these bugs are hard, have gotten a lot of attention, and are probably on a developer's TODO list already. If it is from an older version of KDE, and there are no recent comments, verify them, make a notation, and move on.
  • Don't be afraid to ask the reporter for more info. It's something you can even do without Bugzilla permissions. And reporters will generally prefer being asked one question too many, instead of their report never being dealt with. Just remember to be polite. Ask yourself how you would feel if you got the message you are thinking about sending to a user.
  • Look through the rest of our documentation for more information!

Articles

How to create useful crash reports - This article helps users to prepare their KDE packages such they can create detailed backtraces.

External links


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