for each item, try to describe

  • nature of the problem
  • background why the problem exists
  • how the problem effects the users
  • how the problem should be fixed

why this

  • when users know limitations they can go around them
  • when developpers know about the problem they can help with coming up with better solutions and even help fix the problem
  • it's easier to trust someone if they aknowledge a problem and it's even better when they have a solution for it
  • open source is based on transparency and trust


  • Problem
  • Symptoms
  • Solution


  • privileges
  • modularity
  • release policy

Rank each issue on several criteria

  • Type
    • 7: Crash: Bug causes crash or data loss. Asserts in the Debug release.
    • 6: Major usability: Impairs usability in key scenarios.
    • 5: Minor usability: Impairs usability in secondary scenarios.
    • 4: Balancing: Enables degenerate usage strategies that harm the experience.
    • 3: Visual and Sound Polish: Aesthetic issues
    • 2: Localization:
    • 1: Documentation: A documentation issue
  • Likelihood
    • 5: Blocking further progress on the daily build.
    • 4: A User would abandon the product. Cannot RTM. The Team would hold the release for this bug.
    • 3: A User would likely not deploy the product. Will show up in review. Clearly a noticeable issue.
    • 2: A Pain – users won’t like this once they notice it. A moderate number of users won’t deploy.
    • 1: Nuisance – not a big deal but noticeable. Extremely unlikely to affect deployment.
  • Priority
    • 5: Will affect all users.
    • 4: Will affect most users.
    • 3: Will affect average number of users.
    • 2: Will only affect a few users.
    • 1: Will affect almost no one.