simonmichael/hledger
1
1
Fork 0
mirror of https://github.com/simonmichael/hledger.git synced 2024-12-26 20:02:27 +03:00
Code Issues Projects Releases Wiki Activity

;doc: ISSUES: simpler prioritisation scheme

Browse Source
This commit is contained in:
Simon Michael 2023-12-12 21:41:59 -10:00
parent 0646218205
commit 11090a53ee
1 changed files with 15 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
doc/ISSUES.md
View File

@ -143,35 +143,27 @@ As of 2023 it's not too much of a problem knowing what's high priority to fix.
Still, <https://lostgarden.home.blog/2008/05/20/improving-bug-triage-with-user-pain/>
describes an interesting method of ranking issues by a single "User Pain" metric.
This would be interesting to try at least once for hledger's open issues; it might bring some benefit ?
What adaptation of it might work for the hledger project ? Eg (WIP):
What adaptation of it might work for the hledger project ? Here's a simplified version:
**Type (What type of bug is this?)**
**Severity (What is the severity level of this bug ?)**
- 5: Crash or data loss or privacy/security loss.
- 4: Major usability or documentation issue.
- 3: Minor usability or documentation issue.
- 2: Installability or packaging issue.
- 1: Localisation or internationalisation issue.
- 5: Data loss or privacy/security loss. A user would drop the product.
- 4: Crash or major usability or documentation issue. A user would look for an alternative product.
- 3: Installability, packaging or new user experience issue. A potential user would fail to get started.
- 2: Minor usability or documentation issue. Noticeable but not a big deal.
- 1: Cleanup/design/developer issue. Significant only to developers and design-minded users.
**Priority (How will those affected feel about the bug?)**
**Likelihood (Who is likely to be affected by this bug ?)**
- 5: Blocking further progress on the daily build.
- 4: A User would return the product. Cannot RTM. The Team would hold the release for this bug.
- 3: A User would likely not purchase 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 buy.
- 1: Nuisance – not a big deal but noticeable. Extremely unlikely to affect sales.
- 5: All users.
- 4: Most users.
- 3: A minority of users.
- 2: Only packagers or developers.
- 1: Almost no one.
**Likelihood (Who will be affected by this bug)**
**User Pain = Severity * Likelihood / (Max Severity * Max Likelihood)**
- 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.
**User Pain = Type * Likelihood * Priority / Max Possible Score**
- List all the active bugs in order of User Pain.
- List all the active bugs in order of User Pain (AKA Priority).
- Developers check the Pain List daily and fix the highest pain bugs on the list.
- If there are no bugs left above the current quality bar, they work on feature work.
- When you do stumble upon a bug that will take more than a week to fix, flag it as a ‘killer’ bug (for special treatment).