View source for Obstacles


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.