(adding the guide) |
(→External links: Correct broken link to a more recent HowTo) |
||
| (12 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. | |
| − | + | ||
| − | + | 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 | + | 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. |
| − | + | ||
| − | look | + | |
| − | + | ||
| − | + | ||
| − | + | 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? | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | the | + | |
| − | + | ===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 | ||
description, ask for clarification - if you can't understand what the | description, ask for clarification - if you can't understand what the | ||
reporter means, the developer probably won't be able to either. | reporter means, the developer probably won't be able to either. | ||
| − | + | ||
| − | the cause: Imagine that an app crashes when you save a document. What | + | ''If you can reproduce the behavior, think of ways to <b>narrow down |
| + | 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 58: | Line 23: | ||
you get to use your imagination a little bit, since every bug report is | you get to use your imagination a little bit, since every bug report is | ||
different. | different. | ||
| − | + | ||
| − | config files: trying to reproduce the bug with a newly created user | + | 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 | (and asking the reporter to do the same) is a good way to test | ||
this. | this. | ||
| Line 67: | Line 33: | ||
especially if you choose to concentrate on just one application. | especially if you choose to concentrate on just one application. | ||
| − | + | ==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 78: | 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. | ||
| − | == | + | ===Useful links=== |
| − | *[http:// | + | *[http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging Guide to Bug Triaging] |
| − | + | ||
| − | + | ||
Contents |
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?
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.
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.
KDE TechBase 