proposal for how to prioritize bugs

When we are not nearing the end of the release, these bugs should take priority:

• bugs that block forward progress
  • any bug that makes the build go red or prevents chandler from launching is of course of the highest priority
  • any bug that breaks agreed upon smoke tests
  • any bug necessary for upcoming development work
  • any bug that prevents testing other features
• bugs that result from unfinished features, features that were to be finished in previous milestones
  • we want to encourage features to get finished, so its important to address these bugs before moving on to new features
• bugs that represent "broken windows"
  • the phrase "broken windows" is from Malcom Gladwell's The Tipping Point: the example is that streets with broken windows experience more crime and vandalism, the broken windows create an environment that suggests the wrong behavior. In our circumstance, we want to create an environment of high quality. This guideline is of course subjective.
  • code that needs to be refactored is an example of a broken window
  • performance problems, ui glitches, and other signs of low robustness, low quality can also be broken windows

Of course, some exceptions should be made:

• bugs that can be more efficiently resolved at a later date
  • by development work scheduled for a future milestone
  • by development work best done in another project, e.g. wxWidgets

We want guidelines that allow developers to do their work efficiently, we don't need to be triaging bugs in a way that wastes time and effort to make a demo, especially at each milestone. That said, we need to be addressing bugs as we go if we want to create a high quality product.

Questions:

• how do we prioritize bugs that are extremely hard to reproduce?
• how do we prioritize platform bugs?

-- KatieCappsParlante - 26 Jul 2004