===Limitations===
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
issue
* Problem
* Symptoms
* Solution
areas
* 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.