Revision as of 23:43, 1 April 2010

Initial version by Dario Andres (2010-03). Corrections by Lydia Pintscher

Disclaimer

All this guide is based on my own experience (approximately 2 years) on the KDE bug tracker.

It may not work for you ;)

General Considerations

• Be polite: when you need to request information or feedback be clear and polite, and you will get more information in less time. 
Often Bugzilla is a place which involves discussions (about implementations, or even about contributors). Try to be concise and polite, respecting the others position while describing your own.

• Don't try to do too many things at the same time; otherwise you will end up with a headache.

If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: Quick Introduction to Bugzilla

About getting permissions to work in the bug tracker

Manpower is always needed in a bug tracker, but as any action taken on it may be potentially destructive to other people's work; or it may end up messing things up (and consuming the developers' or other triager's time) the tracker requires special permissions to perform changes in bug reports.

If you want to work in the bug tracker you need to prove that you know what you are doing.

Initially you will ask for support on #kde-bugs (on IRC) and add comments in the bug report (so other people will see and check them, perform the needed actions, and evaluate your work)

 

Note
adding comments in the bug report is allowed for every user

Getting Started: Find what to work on (Different Approaches)

You could use different techniques or approaches to triage the reports according to your current mood or the amount of work you want to do for example.

Note: The two following techniques are complementary.

Check all the bug reports of the day

In this technique you check all the bug reports (of all the products) which were filed today (or some days ago).

You can focus on crash, normal or wish reports individually (recommended) or all of them together.

Good:

• You get a complete view of all the reports
• You can easily recognize possible duplicates if the report titles are appropriate
• You can choose any report
• You can quickly clean the bugs that were filed recently (keeping them from rotting)
• You can get quick feedback from the reporter

Not so Good:

• You don't focus on one product
• You may not pay too much attention to every report, as you are triaging different kinds of reports
• You need a lot of attention to handle the different reports (at the ~same~ time)

This technique could be used every week (or every day)

Bugzilla Links (TODO)

• All the bugs (any type) reported today or the last week
• All the crashes reported today or the last week
• All the normal bugs reported today or the last week
• All the feature requests reported today or the last week

Check bug reports of a product over a period of time

Choose a product (application or library). Then choose a period of time like 1 month or 1 or 2 years (or "from the beginning of the current year"). You can also choose which kind of reports you want to handle.

This technique is useful to audit old bugs or perform a deep clean (in case that the bugs weren't triaged on a daily basis previously).

Good:

• You focus only on one product / topic, so you don't need to pay too much attention (pay attention anyways!)

Not so Good:

• The reports of the other application may rot if they aren't checked
• You may not get feedback if the report is too old or the reporter is not accessible anymore

You can also filter out results (and be even more focused) if you select a custom component inside the product (a subsection of the application).

This technique could be used two times a month.

Bugzilla Links (ToDo)

• Template search for all the reports of any status, since 2008: any kind of report, crashes, normal bugs, feature requests
• Template search for all the open reports, since 2008: any kind of report, crashes, normal bugs, feature requests

Workflow of the bug triaging activity

Handling reports: What to do with a bug report

Trying to reproduce the bugs

Getting bug triaging support

BugWeeks

FAQ

More Information