Bug Triaging

From MusicBrainz Wiki
Revision as of 20:56, 20 September 2006 by DonRedman (talk | contribs) (moved here from KrazyKiwi (Imported from MoinMoin))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Little Guide to Bug Triage

The start of some notes about BugTriage (see the GreatDispute)

Main points, not in any particular order yet, and not nearly ready for comment:

  • Recognise
  • Reproduce
  • Refine
  • Restate
  • Reorganize (ok, assign, but I couldn't resist the alliteration, which was quite by accident until this one, I swear)
  • Spot early which are bugs ("It doesn't work as intended") and which are feature requests ("It doesn't work how I expect/It doesn't work how I want"). Is it an HCI/UI bug? ("It doesn't work how I expect, but does work exactly as intended")
  • Weed out duplicates.
  • Prioritising. There can be several scales of priorities, and they can be quite orthogonal to each other, sometimes even completely in opposition. We should be able to rate on various scales, such as:
    • in order of urgency (not necessarily importance - some things are urgent, but not very important, and some things are very important, but not at all urgent. That's a bit difficult to grok sometimes):
      1. Data is lost (Existing data is damaged or removed, when it shouldn't be). I guess MB doesn't have much possibility of this. Picard may though. Includes "CRASH", if it causes damage to existing data.
      2. User time is lost (Data entry needs to be done over, for instance) Includes "CRASH" if it means you have to redo your tagging.
      3. Data is duplicated because... (bad, but not as bad as a crash making you reenter a whole album)
      4. Interaction: Does this problem cause a chain reaction? Is this potentially related to other problems?
    • in order of importance
      1. Scale of problem (does it affect a thousand edits a day? or one?)
      2. Scale of cleanup (if this isn't fixed in a day or a week or a month, how many edits will need to be reentered? Corrected? removed?)
      3. Scale of fix (hard to judge from outside, but is it a huge change, database schema, or is it a one liner, will it cause an interaction)
      4. Can it be worked around? If there's a known and doable workaround, can we educate people to use it in the mean time?

Other things:

  • Is it reproducible on the test server (if yes, what specifically and exactly are the steps to reproduce it)
  • Is there more than one bug here? If yes, they need splitting

... and more, when I get around to it.


started by KrazyKiwi