From SqueezeboxWiki

Contents 1 Process 2 Bug Triage 3 Attachments 4 Bug Priority Standards 4.1 P1 4.2 P2 4.3 P3 4.4 P4 4.5 P5 5 Bug Severity Standards 5.1 Blocker: 5.2 Critical: 5.3 Major: 5.4 Normal: 5.5 Minor: 5.6 Trivial: 5.7 Enhancement:

Process

The default assignee for bugs will be "unassigned@slimdevices.com". When a new bug is reported it will be assigned to this user. After this, the bug is "triaged" by QA team members. The severity and target will be corrected, and it will be assigned to a person, OR it will be left assigned to "unassigned" and set for "Future". So, all bugs will fall into one of these categories:

1. New, assigned to "unassigned", targeted for "—", not yet "triaged"
2. Assigned to a live person who will conscientiously deal with the bug.
3. Assigned to "unassigned" and targeted for "Future".

Community members are encouraged to talk to the bug assignees (or post to them here on the forums) if there's a particular bug they would like to work on, or they are welcome to work on bugs assigned to "unassigned" with or without assigning such bugs to themselves.

Bugs set for "Future" will be reviewed regularly (no, really) and targeted for an upcoming release as required. Bugs that have been assigned will be reviewed if they have not had any activity for a while, to see if the assignee needs help, or if they no longer have time, or just to see if there's any issue.

At any time, bugs can be assigned to qa@slimdevices.com for research, generating log files, interrogating with end users, or other actions. Bugs can also be assigned to me, chris@slimdevices.com for management attention.

We are not currently considering using some of Bugzilla's other features, such as requiring some number of votes or explicit "confirmation" by an empowered use to get out of an "unconfirmed" state, but if anyone has thoughts on this, we'd be happy to consider them.

Bug Triage

No targeted bug without assignee

We repeatedly go over the same bugs again, because they're first targeted, but still show up on the unassigned bug list. ("future" is not considered a target in this context)

No assignee without a target

Again, "Future" is not considered a target. I usually have enough bugs targeted for a close release not to bother about untargeted or those set to "future". Let's better not assign them.

Let's dare to say "No"

Whenever we remove/change a feature, there will crop up a bunch of enhancement requests about reverting that change. The same applies to features we once decided not to implement. In these cases we should be clear and say "WONTFIX". Or better (if possible) create a reason "DESIGN DECISION". It would then be clear why we won't change this, but could still monitor the request.

Don't re-assign bugs to anybody else without adding a minimum of value

If you're assigned a bug to investigate/fix/reproduce, don't re-assign it without giving a minimum of information. What did you test? What results did you get? Why do you re-assign it? I've seen bugs beeing assigned during scrub meetings, just to be re-assigned a few days later. That's a waste of time for all of us and rather looks like pushing around the hot potatoe.

Only re-open a bug if the reported bug isn't fixed. Don't re-open if you encounter a new (though related) bug while testing the fix.

When a bug is fixed, this gets noted in the changelog. Re-opening needs editing the changelog again. Plus it's sometimes a mess to find the new bug under the old bug's subject, or tracking several bugs under one bug number. Just create a new bug report. It's simple and simplifies tracking issues a lot.

Attachments

• do not attach BMP files if you can help it. PNG or JPEG are preferred
• do not zip attachments unless you have a large set items you need to include
• do not attach (Microsoft) Word / PowerPoint / Excel files
• do not attach *.doc files

Bug Priority Standards

P1

• This bug is so severe it cause the product to be completely unusable, there are no workarounds.

P2

• This bug is so severe it cause the product to be unstable, however, there are workarounds.

P3

• This bug causes the product to be unstable, but not unusable.

P4

• This bug causes a minor inconvenience or annoyance in using the product.

P5

• The bug causes problems, but should be looked at eventualy

Bug Severity Standards

Blocker:

• This bug is so severe it is preventing scheduled development or testing on the affected product.

Critical:

• The bug causes a crash in the affected product, or a fundamental function is not usable
  • Example: the web UI is totally nonfunctional or no audio plays back at all.

Major:

• A core feature of the product is not usable
  • Example: transcoding doesn't work, a localized language doesn't work, or the CLI is broken

Normal:

• Some function of the product is not working correctly.
  • This is the default state for newly created bugs. Please leave bugs in this state, unless one of the above/below criteria is meet.

Minor:

• Some function is not working optimally, but there is no loss of functionality, or there is an easy workaround.

Trivial:

• An irritation. Something is clearly not right, but it does not affect usability.

Enhancement:

• A request for a change or new feature to improve the product in the future.

You may also want to read the Bugzilla User's Guide to find out more about Bugzilla and how to use it.