48 KiB
Issues
The hledger project's issue tracker is on github.
Convenience urls:
- https://issues.hledger.org - all issues, open or closed
- https://bugs.hledger.org - open BUGs
- https://wishes.hledger.org - open WISHes
- https://prs.hledger.org - open pull requests
- https://readyprs.hledger.org - open pull requests ready for review
- https://draftprs.hledger.org - open draft pull requests
- https://bugs.hledger.org/new - report a new issue
- https://hledger.org/regressions - how to claim regression bounties
Misc. issue queries:
- critical bugs, and major bugs affecting many users
- major bugs affecting fewer users
- bugs without an impact label
- bugs without a severity label
- issues needing old bountysource boilerplate removed
(Most older issues don’t have impact/severity labels, so those reports are recent-biased)
Open issues grouped by topic/type:
Labels
In the github issue tracker we use labels to categorise things like:
- whether an issue is a bug (red) or a wish (purple)
- bug impact - who is affected (light yellow)
- bug severity - how annoying is it (light pink)
- which subcomponents (tools, commands, input/output formats) are involved (light blue)
- which platforms are involved (blue)
- regressions (black)
- security issues (bright red)
- issues with bounties (bright green)
- PRs needing release (yellow)
- PR blockers (grey)
- miscellaneous (white)
The subcomponent names are also used in commit message prefixes, in issue title prefixes, etc.
Some other loose conventions:
We sometimes prefix bug titles (especially regressions) with the hledger version(s) affected. This allows searches like new issues in 1.22 and regressions in 1.22
In the past we tracked some time estimates in brackets after the issue title. The format was something like
[ESTIMATEDTOTALTASKTIME|TIMESPENTSOFAR]. Eg:[2]two hours estimated, no time spent yet[..]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|2d]initially estimated as one hour, later estimated as one week, two days spent so far
Prioritising
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. Here’s the simplified version that we are using in the hledger issue tracker:
Two labels can be
applied to bug reports, each beginning with the letter a so
as to appear near the front of label lists, each with a level from 1 to
5:
Impact
Who may be affected by this bug ?
- affects1-noone: Affects almost no one.
- affects2-devs: Affects packagers or developers.
- affects3-few: Affects just a few users.
- affects4-many: Affects potentially a significant number of users.
- affects5-most: Affects most or all users.
Severity
To people affected, how serious is this bug ?
- annoyance1-trivial: Cleanliness/consistency/developer bug. Only perfectionists care.
- annoyance2-minor: Minor to moderate usability/doc bug, reasonably easy to avoid or tolerate.
- annoyance3-blocker: New user experience or installability bug. A potential user could fail to get started.
- annoyance4-major: Major usability/doc bug, or any regression or crash.
- annoyance5-critical: Any loss of user’s data, privacy, security, or trust.
User Pain
The bug’s User Pain score is Impact * Severity * 4, so ranging from 4 to 100.
Then, practices like these are possible:
- All open bugs can be listed in order of User Pain (AKA priority).
- Developers can check the Pain List daily and fix the highest pain bugs on the list.
- The team can set easy-to-understand quality bars. For example, they could say “In order to release, we must have no open bugs with more than 50 pain.”
- If there are no bugs left above the current quality bar, they can work on feature work.
- If a bug is found that will take more than a week to fix, it can be flagged as a ‘killer’ bug, for special treatment.
Reducing bugs and regressions
Some ideas in 2024-01:
- Maintain ratio of user-visible bugfixes to new features, eg above 10:1 (a new master merge test, human checked)
- A release cycle with no new features
- Alternate bugfix and feature release cycles
- Set bug count targets
- Label all issues for impact/severity/user pain; set max user pain targets
- Gate releases on user pain targets or other bug metrics
- Document and follow more disciplined bug triage/fixing methods
- Identify every new bug early as a regression/non-regression
- Prioritise rapid fixing and releasing for regressions / new bugs
- Cheaper, more frequent bugfix releases
- More intentional systematic tests ? Analyse for weak spots ?
- Property tests ?
- Internal cleanup, architectural improvements, more type safety ?
- Custom issue dashboards (HTMX on hledger.org ?)
- Public list / QA dashboard
- Grow a QA team
Older ideas
- Custodians for particular components/topics (“If you are interested in helping with a particular component for a while, please add yourself as a custodian in the Open Issues table. 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.”)
Other
In 2017 we experimented with Github projects, in 2018 with Github milestones.
Long ago we collected some wishlist items in a trello board (trello.hledger.org).