Bug Management Guidelines

This is a personal experiment to see if we can create an effective set of guidelines for bug management. It is work in progress.

Contents

Always replace the UNCONFIRMED status
Prioritize
Direct contributors using searches
Be bold but friendly
Clean your bugs regularly
Related Links
Comments

These guidelines are intended to help developers and maintainers manage their bugs. They aim to do this by providing a simple set of procedures that will:

Give you a clear set of bugs that are interesting for contributors.
Establish a simple routine for processing new bugs.
Focus your team and help you set goals.

Remember: Bugzilla is a task tracking tool. It exists to help contributors find tasks to work on. Don't let it turn into a encyclopedia of every possible issue with your software.

1. Always replace the UNCONFIRMED status

Work in order to eliminate uncertainty from your bugs. Always replace the UNCONFIRMED status with:

Status	Description
NEEDINFO	More information is needed to decide whether the bug is valid or not.
NEW	Valid bugs (ie. you are confident that the issue is real).
NEW + design_needed whiteboard*	The bug is valid but doesn't have a design yet.
NEW + available whiteboard*	Bug is valid and a resolution has been identified - it is ready to be fixed.
RESOLVED WONTFIX	Bugs that are not sufficiently important, cannot be resolved within the current design, or the fix is undesirable.

When making status changes, eliminate uncertainty by explaining decisions. For example, when setting the status to NEW, it is a good idea to reference the agreed fix to the bug.

* In the future, we might want to make these into keywords.

2. Prioritize

Bugzilla is how you and your team decide what to work on, so it is a good idea to make sure that your bugs reflect your priorities.

Ensure that you always have a short list of bugs that indicate the direction you want to take the module in, and mark their priority as high. This is a great way to point contributors to the most important bugs.

3. Direct contributors using searches

Once you have a good collection of NEW bugs, including bugs with the ready and gnome-love keywords or with assigned priorities, you can point contributors to them.

Creating searches for important groups of bugs and linking to them from your wiki page and IRC topic is a great way to direct contributors to tasks.

4. Be bold but friendly

If you want to keep your bug count under control and focus your team, you have to mark bugs as RESOLVED or NEEDINFO. The only way to succeed is to make bold decisions.

Being bold does not mean being unfriendly or authoritarian though. It is actually helpful to acknowledge your own fallibility. There is no harm in pointing out that a decision can be changed.

Remember, all changes can be undone and no bug is ever deleted. If an issue is important, it will be reported again or will receive comments.

5. Clean your bugs regularly

To manage your bugs effectively, you need to routinely clean them. Try to perform a series of checks every few days. In particular, you should review:

Newly reported UNCONFIRMED bugs
Unreviewed patches
gnome-love and target milestones (to ensure they are populated)
NEEDINFO bugs (are there any with recent activity; are there any that are dead and can be closed?)