|
|
| Line 1: |
Line 1: |
| == Introduction ==
| | Moved to [[Guidelines and HOWTOs/Bug triaging]] |
| 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 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 [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,
| |
| 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 <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?
| |
| 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.
| |
| | |
| ==20-second summary==
| |
| ===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.
| |
| ===Useful links===
| |
| *[[Bugsquad/Guide_To_BugTriaging | Guide to Bug Triaging]]
| |
