Contribute/Bugsquad/Guide - Revision history

Mamarok: /* External links */ Correct broken link to a more recent HowTo

2011-10-19T20:17:50Z

‎External links: Correct broken link to a more recent HowTo

DarioAndres at 13:59, 31 October 2009

2009-10-31T13:59:22Z

Tampakrap at 09:27, 28 October 2006

2006-10-28T09:27:21Z

Cullmann: Bug triage/Guide moved to Contribute/Bugsquad/Guide

2006-09-28T13:38:24Z

Bug triage/Guide moved to Contribute/Bugsquad/Guide

Logixoul: Bugsquad/Triage guide moved to Bug triage/Guide

2006-09-13T19:13:46Z

Bugsquad/Triage guide moved to Bug triage/Guide

Logixoul: Triage guide moved to Bugsquad/Triage guide: structure

2006-09-09T07:43:52Z

Triage guide moved to Bugsquad/Triage guide: structure

Logixoul: /* External links */

2006-09-08T12:43:30Z

‎External links

Logixoul: /* External links */

2006-09-08T12:40:14Z

‎External links

Logixoul at 12:38, 8 September 2006

2006-09-08T12:38:47Z

Logixoul at 12:37, 8 September 2006

2006-09-08T12:37:25Z

@@ Line 44: / Line 44: @@
 '''What skills do I need to do it?''' Not much, just a bit of
 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]

@@ Line 1: / Line 1: @@
 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?
-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,
 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.
-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?
 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
-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
 this.
@@ Line 32: / Line 33: @@
 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
@@ Line 43: / Line 44: @@
 '''What skills do I need to do it?''' Not much, just a bit of
 patience and sometimes some perseverance.
-==External links==
+===External links===
 *[http://quality.kde.org/develop/howto/howtobugs.php Reports Management HOWTO]

← Older revision		Revision as of 09:27, 28 October 2006
Line 45:		Line 45:
	==External links==		==External links==
	*[http://quality.kde.org/develop/howto/howtobugs.php Reports Management HOWTO]		*[http://quality.kde.org/develop/howto/howtobugs.php Reports Management HOWTO]
		+	*[http://developer.kde.org/build/stable.html Compiling guide]

← Older revision		Revision as of 12:43, 8 September 2006
Line 45:		Line 45:
	==External links==		==External links==
	*[http://quality.kde.org/develop/howto/howtobugs.php Reports Management HOWTO]		*[http://quality.kde.org/develop/howto/howtobugs.php Reports Management HOWTO]
−	*[http://lists.kde.org/?l=kde-devel&m=115680867120569&w=2 An opinion on bug triage]

@@ Line 44: / Line 44: @@
 patience and sometimes some perseverance.
 ==External links==
-*[http://quality.kde.org/develop/howto/howtobugs.php|Reports Management HOWTO]
+*[http://quality.kde.org/develop/howto/howtobugs.php Reports Management HOWTO]
-*[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]
-*[http://lists.kde.org/?l=kde-devel&m=115680867120569&w=2|An opinion on bug triage]

@@ Line 1: / Line 1: @@
 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 probably 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 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.
-So, once you've got an account on bugs.kde.org and read 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.
-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
+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?
 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: