Managing software issues
Managing software issues¶
Code has bugs. It also has features, things it should do.
A good project has an organised way of managing these. Generally you should use an issue tracker.
Some Issue Trackers¶
There are lots of good issue trackers.
Commercial solutions include Jira.
In this course, we’ll be using the GitHub issue tracker.
Anatomy of an issue¶
Type [Bug, Feature]
Reporting a Bug¶
The description should make the bug reproducible:
If possible, submit a minimal reproducing code fragment.
Owning an issue¶
Whoever the issue is assigned to works next.
If an issue needs someone else’s work, assign it to them.
Will Not Fix
Not a bug (working as intended)
Some organisations use a severity matrix based on:
Severity [Wrong answer, crash, unusable, workaround, cosmetic…]
Frequency [All users, most users, some users…]
The list of all the bugs that need to be fixed or features that have been requested is called the “backlog”.
Development goes in cycles.
Cycles range in length from a week to three months.
In a given cycle:
Decide which features should be implemented
Decide which bugs should be fixed
Move these issues from the Backlog into the current cycle. (Aka Sprint)