User:Grundleborg/TriageGuide: Difference between revisions

From KDE TechBase
No edit summary
("pick a bug to triage" adds)
 
(8 intermediate revisions by one other user not shown)
Line 1: Line 1:
This page contains step by step instructions to get you set up to triage bugs.
{{Tip|This page contains step by step instructions to get you set up to triage bugs.}}
==Open a Bugzilla Account==
If you do not already have one, you should open an account on [http://bugs.kde.org/createaccount.cgi bugs.kde.org]. This will enable you to log in and comment on bugs.


==1) Open a Bugzilla Account==
==Join the Mailing List and IRC Channel==
If you do not already have one, you should open an account on [http://bugs.kde.org/createaccount.cgi | bugs.kde.org]. This will enable you to log in and comment on bugs.
You should join the [http://list.kde.org bugsquad mailing list] to keep up to date on the latest bugsquad happenings. We also gather in #kde-bugs on irc.freenode.net where you are welcome to ask any questions you have. We are happy to guide you through your first few bug triages!


==2) Join the Mailing List and IRC Channel==
==Pick a Bug to Triage==
You should join the [http://list.kde.org bugsquad mailing list] to keep up to date on the latest bugsquad happenings. We also gather in #kde-bugs on irc.freenode.net where you are welcome to ask any questions you have.
Choose a bug to triage. Pick any bug you like - a good place to start is with an application you use regularly and are familiar with. You can use bugzilla's [http://bugs.kde.org/query.cgi query interface] to search for bugs to triage. Look at newly filed bugs, this is a good place to start. You can modify the search to narrow it to the application of your choice. If a bug has lots of comments on it from different people, it is likely that the developers are paying attention to it. So look for things that have slipped through the cracks.


==3) Pick a Bug to Triage==
==Find out what needs to be changed==
tbc
Read through [[StepsOfTriagingBugs|The Steps of Triaging a Bug]] to learn what to do once you have chosen a bug to triage.


==4) Find out what needs to be changed==
==Get your changes verified==
Making mistakes when triaging bugs waste developers' time, and they don't like it. So, before making any changes to a bug, you should get a second opinion. You can either ask on our irc channel, #kde-bugs (on irc.freenode.net), or failing that, use the [[OutstandingBugChanges|Outstanding Bug Changes]] page to record the bug and another triager will check that they agree with your proposed changes.


==5) Get your changes verified==
==Make your changes==
Once your proposed changes have been verified (and likely amended) by another triager, you can make the changes in Bugzilla. If you do not have the required permissions to make a change, you should list the bug on the [[OutstandingBugChanges|Outstanding Bug Changes]] page. Then someone who does have the required permissions will make the change for you.


==6) Make your changes==
==Repeat steps 3-6 above==
 
Now you have triaged your first bug, repeat the process for as many more as you like. If you triage loads of bugs, you might even find youself mentioned in the [http://commit-digest.org/issues/latest/#stats_bugkillers commit-digest]!
 
 
(Many thanks to the gnome bugsquad for having such excellent wiki pages to pillage :) )

Latest revision as of 00:45, 4 April 2008

Tip
This page contains step by step instructions to get you set up to triage bugs.

Open a Bugzilla Account

If you do not already have one, you should open an account on bugs.kde.org. This will enable you to log in and comment on bugs.

Join the Mailing List and IRC Channel

You should join the bugsquad mailing list to keep up to date on the latest bugsquad happenings. We also gather in #kde-bugs on irc.freenode.net where you are welcome to ask any questions you have. We are happy to guide you through your first few bug triages!

Pick a Bug to Triage

Choose a bug to triage. Pick any bug you like - a good place to start is with an application you use regularly and are familiar with. You can use bugzilla's query interface to search for bugs to triage. Look at newly filed bugs, this is a good place to start. You can modify the search to narrow it to the application of your choice. If a bug has lots of comments on it from different people, it is likely that the developers are paying attention to it. So look for things that have slipped through the cracks.

Find out what needs to be changed

Read through The Steps of Triaging a Bug to learn what to do once you have chosen a bug to triage.

Get your changes verified

Making mistakes when triaging bugs waste developers' time, and they don't like it. So, before making any changes to a bug, you should get a second opinion. You can either ask on our irc channel, #kde-bugs (on irc.freenode.net), or failing that, use the Outstanding Bug Changes page to record the bug and another triager will check that they agree with your proposed changes.

Make your changes

Once your proposed changes have been verified (and likely amended) by another triager, you can make the changes in Bugzilla. If you do not have the required permissions to make a change, you should list the bug on the Outstanding Bug Changes page. Then someone who does have the required permissions will make the change for you.

Repeat steps 3-6 above

Now you have triaged your first bug, repeat the process for as many more as you like. If you triage loads of bugs, you might even find youself mentioned in the commit-digest!