Difference between revisions of "Contribute/Bugsquad/How to triage bugs"

Jump to: navigation, search
(let's give teve's bugzilla name ;))
(add some sections)
Line 1: Line 1:
 
(from a barely edited irc log, with nixeagle's permission)
 
(from a barely edited irc log, with nixeagle's permission)
  
[02:14] <nixeagle> alot of the bugs look like "load site, does issue still exist" variety :P
+
=See if the bug still exists=
  
 
If there isn't a testcase, see if you can make one. That can be time consuming. If there is one, it should be in the subject line
 
If there isn't a testcase, see if you can make one. That can be time consuming. If there is one, it should be in the subject line
Line 21: Line 21:
 
If you know what piece of code fixed it (usually we won't, but a dev would), then you close with FIXED
 
If you know what piece of code fixed it (usually we won't, but a dev would), then you close with FIXED
  
The nice way of closing bugs that don't have enough information and you think are likely to be invalid at this point is REMIND. And add a note saying "if this is still a problem, please reopen with more information."
+
The nice way of closing bugs that don't have enough information and you think are likely to be invalid at this point is REMIND. And add a note saying "if this is still a problem, please reopen with more information."  
REMIND is useful
+
  
{{tip| We aren't very likely to come across duplicates. Tommi Tervo is very good at catching those, and has likely gone through all the older bugs at some point over the years. Always get a second opinion, traditionally dups are the highest false positives, and we do not want to close valid, real bugs. Last time, we ended up with only 2 duplicates, out of 355 bugs.}}
+
{{tip| We aren't very likely to come across duplicates. Tommi Tervo is very good at catching those, and has likely gone through all the older bugs at some point over the years. Always get a second opinion, traditionally dups are the highest false positives, and we do not want to close valid, real bugs. Last time, we ended up with only 3 duplicates, out of 355 bugs.}}
  
  
<nixeagle> mmm right, and if I can still replicate, what do I do?
+
==if I can still replicate a bug==
<blauzahl> see if it has a testcase, see if you can write one, put it on the wiki
+
See if it has a testcase, see if you can write one, put it on the wiki. Add a note saying the bug is still present and agian, and don't forget to give what version you're using.
<blauzahl> oh, and add a note saying the bug is still present and agian, and don't forget to give what version you're using.
+
  
<nixeagle> ok, so I put all bugs I look at on the wiki?
 
<blauzahl> pretty much. it gives us an easy way to go through and double check what people have done, especially useful for those who don't have bugzilla perms
 
  
<nixeagle> ok, where on the wiki do I edit  
+
==put all bugs you look at on the wiki==
<blauzahl> depends on what section
+
It gives us an easy way to go through and double check what people have done, especially useful for those who don't have bugzilla perms
 +
 
 +
==Where on the wiki do I edit?==
 +
Depends on what section
 
If you go up a level or so from the link in the topic, you'll find the one from the last time we did this
 
If you go up a level or so from the link in the topic, you'll find the one from the last time we did this
 
  http://techbase.kde.org/index.php?title=Contribute/Bugsquad/BugDays/
 
  http://techbase.kde.org/index.php?title=Contribute/Bugsquad/BugDays/
Line 41: Line 40:
 
We're not putting any new bugs on there.
 
We're not putting any new bugs on there.
  
We also use the wiki to some extent to coordinate comments, not so much
+
We also use the wiki to some extent to coordinate comments, at least to document what we said in irc.
[02:29] <nixeagle> this page is going to get big
+
[02:29] <blauzahl> it does
+
[02:29] <blauzahl> we're open to suggestions for a new system :)
+
[02:29] <blauzahl> cause this won't scale ;)
+
(We'll see how well what we have now works, thanks nixeagle!)
+
  
[02:32] <nixeagle> blauzahl, also...if you don't mind me asking, how many open bugs are against KDE as a whole?
+
We want to keep it all on one page, because on the 2nd and 3rd pass, we tend to move things around a LOT from section to section as stuff changes.
 +
 
 +
==how many open bugs are against KDE as a whole?==
 
A ton. You can check at ...
 
A ton. You can check at ...
  
If you just got a techbase wiki account, set the preferences to let you edit by section.
+
{{Tip|If you just got a techbase wiki account, set the preferences to let you edit by section.}}
 
+
We want to keep it all on one page, because on the 2nd and 3rd pass, we tend to move things around a LOT from section to section as stuff changes.
+

Revision as of 21:17, 17 April 2008

(from a barely edited irc log, with nixeagle's permission)

Contents

See if the bug still exists

If there isn't a testcase, see if you can make one. That can be time consuming. If there is one, it should be in the subject line

And on the "site-issue" bugs, it's entirely likely that it's a 6 year old site which has long vanished so read the comments, because there might be a useful testcase or something describing what was the problem in there. If it looks like there's enough to give a developer something to go on, put it under the "needs attention from dev" section.

If it has a testcase, toss it into the testcase section

If it has little information, and the site doesn't exist ---> INVALID *g*

If you can't change bugs other then comment, then just write your comment on the bug, always include your version (and distro if applicable) number, and then write it on the wiki. Someone will go through and double check stuff and mark what should be marked for you.

If you aren't sure about something, get a second opinion, and mention who seconded on the wiki, especially if it was a dev. And you'll have your own bugzilla perms in no time

If it works for us, then we close with WORKSFORME

If you know what piece of code fixed it (usually we won't, but a dev would), then you close with FIXED

The nice way of closing bugs that don't have enough information and you think are likely to be invalid at this point is REMIND. And add a note saying "if this is still a problem, please reopen with more information."

Ktip.png
 
Tip
We aren't very likely to come across duplicates. Tommi Tervo is very good at catching those, and has likely gone through all the older bugs at some point over the years. Always get a second opinion, traditionally dups are the highest false positives, and we do not want to close valid, real bugs. Last time, we ended up with only 3 duplicates, out of 355 bugs.


if I can still replicate a bug

See if it has a testcase, see if you can write one, put it on the wiki. Add a note saying the bug is still present and agian, and don't forget to give what version you're using.


put all bugs you look at on the wiki

It gives us an easy way to go through and double check what people have done, especially useful for those who don't have bugzilla perms

Where on the wiki do I edit?

Depends on what section If you go up a level or so from the link in the topic, you'll find the one from the last time we did this

http://techbase.kde.org/index.php?title=Contribute/Bugsquad/BugDays/

You'll see how it's ended up looking now that we've gone through it a few times We're not putting any new bugs on there.

We also use the wiki to some extent to coordinate comments, at least to document what we said in irc.

We want to keep it all on one page, because on the 2nd and 3rd pass, we tend to move things around a LOT from section to section as stuff changes.

how many open bugs are against KDE as a whole?

A ton. You can check at ...

Ktip.png
 
Tip
If you just got a techbase wiki account, set the preferences to let you edit by section.

KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal