29 KiB
Issues
The hledger project's issue tracker is on github. It contains:
- BUG issues - failures in some part of the hledger project (the main hledger packages, docs, website..)
- WISH issues - feature proposals, enhancement requests
- uncategorised issues - we don't know what these are yet
- pull requests - proposed changes to code and docs
Quick urls
- http://issues.hledger.org - all issues, open or closed
- http://bugs.hledger.org - open BUGs
- http://wishes.hledger.org - open WISHes
- http://prs.hledger.org - open pull requests
- http://readyprs.hledger.org - open pull requests ready for review
- http://draftprs.hledger.org - open draft pull requests
- http://bugs.hledger.org/new - report a new issue
- <https://hledger.org/regressions - how to claim the regression finder's bounty
Open issues
Some loose conventions:
- In bug titles, mention the hledger version in which the bug first appeared (and avoid mentioning version numbers otherwise). This allows searches like new issues in 1.22 and regressions in 1.22
Labels
https://github.com/simonmichael/hledger/labels, also listed at open issues above, are used to categorise:
- whether an issue is a bug (red) or a wish (pink)
- related subcomponents (tools, commands, input/output formats) (light blue)
- related general topics (light green)
- related platforms (light purple)
- whether a bounty has been offered (dark green)
- why an issue is blocked (dark grey) or was closed (black)
- low priority info, like "imported" (white)
Labels can also be used as prefixes in issue/PR titles, as prefixes in commit messages, etc.
Custodians
If you are interested in helping with a particular component for a while, please add yourself as a custodian in Open Issues table above. A custodian's job is to help manage the issues, rally the troops, and drive the open issue count towards zero. The more custodians, the better! By dividing up the work this way, we can scale and make forward progress.
Milestones and Projects
Milestones are used a little bit to plan releases. In 2017 we experimented with projects, but in 2018 milestones are in favour again..
Estimates
You might see some experiments in estimate tracking, where some issue names might have a suffix noting estimated and spent time. Basic format:
ESTIMATEDTOTALTASKTIME\|TIMESPENTSOFARhours estimated, no time spent [..] half an hour estimated (a dot is ~a quarter hour, as in timedot format) [1d] one day estimated (a day is ~4 hours) [1w] one week estimated (a week is ~5 days or ~20 hours) [3|2] three hours estimated, about two hours spent so far
1\|1w\|2dtwo days spent so far ``` Estimates are always for the total time cost (not time remaining). Estimates are not usually changed, a new estimate is added instead. Numbers are very approximate, but better than nothing.
Trello
The trello board (trello.hledger.org) is an old collection of wishlist items. This should probably be considered deprecated.
Prioritising
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):
Type (What type of bug is this?)
- 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.
Priority (How will those affected feel about the 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.
Likelihood (Who will be affected by this bug)
- 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.
- 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).