Difference between revisions of "Contribute/Bugsquad/Guide"

Jump to: navigation, search
(External links: Correct broken link to a more recent HowTo)
 
(11 intermediate revisions by 4 users not shown)
Line 1: Line 1:
I've got a little bit of free time, so here's the first in what will
+
== Introduction ==
hopefully become a series of hints and tips about getting involved in
+
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.
KDE without having to learn C++.
+
  
Today's topic is bug triage. Around 80 new bugs and wishlist items are
+
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.
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.
+
  
The really nice thing about bug triage is that it comes in very small,
+
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.
bite-sized chunks: each bug report probably takes a few minutes to
+
look through, so you can spend ten minutes a day on bug triage (on
+
your coffee break!), and be able to do something useful - something
+
that isn't so practical with some other ways of helping KDE.
+
  
The main reference for bug triaging, which I'd thoroughly recommend,
+
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?
is the [http://quality.kde.org/develop/howto/howtobugs.php quality.kde.org
+
bugs howto]. That'll give you some pointers for getting started,
+
and tell you a little about how the bug tracking system works, what
+
the different bug statuses mean, and so on.
+
  
So, once you've got an account on bugs.kde.org and read the
+
===Some things to do===
quality.kde.org howto, what do you do next? 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
+
First, '''try to reproduce the behavior''' that the reporter has
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:
+
 
+
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 53: 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 62: 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 70: 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 81: 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]
*[http://accentgrave.blogspot.com/2006/03/ive-got-little-bit-of-free-time-so.html|getting involved in KDE without having to learn C++]
+
*[http://lists.kde.org/?l=kde-devel&m=115680867120569&w=2|An opinion on bug triage]
+

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,554 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