(→How to help) |
(→Getting started) |
||
| Line 35: | Line 35: | ||
* 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. | * 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. | * 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 at the incoming Bugzilla bugs. Or find the oldest bugs for your favorite software application. | ||
* Look through the rest of our documentation for more information! | * Look through the rest of our documentation for more information! | ||
| Tip |
|---|
| Thanks to all who took part on 6th April. The date of the next BugDay will be decided soon. |
Contents |
The KDE BugSquad keeps track of incoming bugs in KDE software, and goes through old bugs. We verify that a bug exists, and is reproducible, and that the reporter has given enough information. When applicable, we write testcases. Our end goal is to help developers notice valid bugs quicker, and to save their time.
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 to learn programming, it is a great way to gain familiarity with the components.
We have regular days where we pick a software package and look through all the old Bugzilla bugs to see if they are still valid. Sort of a Bugzilla cleaning day.
The date for the next Bug Day has not yet been decided, but will probably be very soon. 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.
Read the guide and join us for one of our bug days. We meet on IRC in the #kde-bugs channel on irc.freenode.org. You can easily get started by having your questions answered there, and having someone guide you as to general bug triaging philosophy. 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:
The sheer number of open bugs can be overwhelming at the start. Here are some hints on getting started more smoothly:
How to create useful crash reports - This article helps users to prepare their KDE packages such they can create detailed backtraces.
KDE TechBase 