Difference between revisions of "Contribute/Bugsquad/Guide"

Jump to: navigation, search
(External links)
(External links: Correct broken link to a more recent HowTo)
 
(5 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 +
== Introduction ==
 
Around 80 new bugs and wishlist items are filed in [http://bugs.kde.org/ KDE's bug tracking system] every day, and, while application and library maintainers try to look at all of the ones reported for their application, their job is a lot easier if someone else has already gone through and removed the duplicates, asked the reporter for any additional information that's useful, and noted which bugs can be reproduced.
 
Around 80 new bugs and wishlist items are filed in [http://bugs.kde.org/ KDE's bug tracking system] every day, and, while application and library maintainers try to look at all of the ones reported for their application, their job is a lot easier if someone else has already gone through and removed the duplicates, asked the reporter for any additional information that's useful, and noted which bugs can be reproduced.
  
Line 7: Line 8:
 
Let's say you decide to concentrate on bugs in one particular app. You can use the [http://bugs.kde.org/query.cgi query page] to display all the open bugs for that application, or just the bugs that have been opened in the last few days. Take a look at each bug, with the aim of determining whether or not the behavior that the reporter described is really a bug, and if so, making it easier for the developer to fix it. Put yourself in the shoes of the developer - what extra information will they need to be able to start fixing the bug?
 
Let's say you decide to concentrate on bugs in one particular app. You can use the [http://bugs.kde.org/query.cgi query page] to display all the open bugs for that application, or just the bugs that have been opened in the last few days. Take a look at each bug, with the aim of determining whether or not the behavior that the reporter described is really a bug, and if so, making it easier for the developer to fix it. Put yourself in the shoes of the developer - what extra information will they need to be able to start fixing the bug?
  
Some things to do:
+
===Some things to do===
  
First, try to reproduce the behavior that the reporter has
+
First, '''try to reproduce the behavior''' that the reporter has
 
described. Add a comment to say whether you could reproduce the bug,
 
described. Add a comment to say whether you could reproduce the bug,
 
noting your KDE version and distribution. If you don't understand the
 
noting your KDE version and distribution. If you don't understand the
Line 15: Line 16:
 
reporter means, the developer probably won't be able to either.
 
reporter means, the developer probably won't be able to either.
  
If you can reproduce the behavior, think of ways to narrow down
+
''If you can reproduce the behavior, think of ways to <b>narrow down
the cause: Imagine that an app crashes when you save a document. What
+
the cause</b>'': Imagine that an app crashes when you save a document. What
 
about selecting Save from the File menu? What about pressing Ctrl+S?
 
about selecting Save from the File menu? What about pressing Ctrl+S?
 
Does it happen for any document, or just certain documents (perhaps
 
Does it happen for any document, or just certain documents (perhaps
Line 24: Line 25:
  
 
Try to find out whether the bug is related to a problem with
 
Try to find out whether the bug is related to a problem with
config files: trying to reproduce the bug with a newly created user
+
''config files'': trying to reproduce the bug with a newly created user
 
(and asking the reporter to do the same) is a good way to test
 
(and asking the reporter to do the same) is a good way to test
 
this.
 
this.
Line 32: Line 33:
 
especially if you choose to concentrate on just one application.
 
especially if you choose to concentrate on just one application.
  
So, in 20-second summary:
+
==20-second summary==
==Bug triage==
+
===Bug triage===
  
 
'''Why is it useful?''' It makes bug hunting and fixing easier for
 
'''Why is it useful?''' It makes bug hunting and fixing easier for
Line 43: Line 44:
 
'''What skills do I need to do it?''' Not much, just a bit of
 
'''What skills do I need to do it?''' Not much, just a bit of
 
patience and sometimes some perseverance.
 
patience and sometimes some perseverance.
==External links==
+
===Useful links===
*[http://quality.kde.org/develop/howto/howtobugs.php Reports Management HOWTO]
+
*[http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging Guide to Bug Triaging]

Latest revision as of 21:17, 19 October 2011

Contents

[edit] Introduction

Around 80 new bugs and wishlist items are filed in KDE's bug tracking system every day, and, while application and library maintainers try to look at all of the ones reported for their application, their job is a lot easier if someone else has already gone through and removed the duplicates, asked the reporter for any additional information that's useful, and noted which bugs can be reproduced.

The really nice thing about bug triage is that it comes in very small, bite-sized chunks: each bug report takes a few minutes to look through, so you can spend ten minutes a day on bug triage, and be able to do something useful - something that isn't so practical with some other ways of helping KDE.

The first thing to do is decide which bugs to concentrate on: do you want to look just the bugs for one or two applications, or take an overview of all bugs that are reported? If you're a long term KDE user, and are a little bit familiar with the internals, then taking an overview might be for you: you'll be able to see when bugs are filed against the wrong KDE component, and suggest what other parts of KDE could be relevant to the bug. If you're not familiar with the internals of KDE, you can still do bug triage! Just pick an application you use a lot, or particularly like, and concentrate on the bugs that are reported for that application.

Let's say you decide to concentrate on bugs in one particular app. You can use the query page to display all the open bugs for that application, or just the bugs that have been opened in the last few days. Take a look at each bug, with the aim of determining whether or not the behavior that the reporter described is really a bug, and if so, making it easier for the developer to fix it. Put yourself in the shoes of the developer - what extra information will they need to be able to start fixing the bug?

[edit] Some things to do

First, try to reproduce the behavior that the reporter has described. Add a comment to say whether you could reproduce the bug, noting your KDE version and distribution. If you don't understand the description, ask for clarification - if you can't understand what the reporter means, the developer probably won't be able to either.

If you can reproduce the behavior, think of ways to narrow down the cause: Imagine that an app crashes when you save a document. What about selecting Save from the File menu? What about pressing Ctrl+S? Does it happen for any document, or just certain documents (perhaps certain file formats)? What about local vs remote files? This is where you get to use your imagination a little bit, since every bug report is different.

Try to find out whether the bug is related to a problem with config files: trying to reproduce the bug with a newly created user (and asking the reporter to do the same) is a good way to test this.

Those are some common, simple things that I can think of. As you get more experienced, you'll find other tips n' tricks that are useful, especially if you choose to concentrate on just one application.

[edit] 20-second summary

[edit] Bug triage

Why is it useful? It makes bug hunting and fixing easier for developers, so more bugs get fixed.

Why choose bug triage instead of ...? It doesn't take much time to look over a bug, so it comes in nice small chunks

What skills do I need to do it? Not much, just a bit of patience and sometimes some perseverance.

[edit] Useful links


This page was last modified on 19 October 2011, at 21:17. This page has been accessed 8,524 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal