Bugzilla Guidelines

Summary

We are using Bugzilla on this project for two types of bugs:

• Site functionality bugs - errors, UI issues.
• Multiple page content problems - when an issue is related to entire groups of pages (otherwise, when an issue is related to a specific page, use the page flags).

Use the following guidelines:

1. If it not in bugzilla, it doesn’t exist. If you are working on something that takes more than an hour or that you can’t get to immediately, please log it as a bug. That includes marketing tasks.

2. First, check if there is an existing bug report on your issue. If so, add a comment there instead. (Duplicate bug reports cost us time.)

3. All bugs should include:

   • reproduction steps,
   • URLs,
   • browser type and version,
   • when you found the bug,
   • and screenshots if a UI issue

4. Priority changes should only be done when initially creating the bug, or by me or one of the following TF leads only:

   • Content: Janet, Chris, Eliot, Doug
   • Marketing: Alex, Christos, Ian
   • Infrastructure: Doug, Alex
   • Hackathon: Peter

5. Assign all bugs to someone specific, and not Doug Null and not a group in general. If in doubt, assign to me: ssweeney@arborheights.net.

6. Assign to one of the TF leads when possible and have them do any delegatation. During the war room, we need to be able to discuss each and every bug. If a bug is assigned to someone not in the war room, I need the TF leads to at least understand the latest with those bugs and be able to discuss the bug in the war room.

7. Our priority system:

   • Pri 1 - Must have, can’t release without
   • Pri 2 - Should have, release will suffer without it
   • Pri 3 - Nice to have
   • Pri 4 - Next release, out of scope for sure for this release

Here’s where to file webplatform.org bugs.