6.8 Managing software issues#

Estimated time for this notebook: 5 minutes


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.

The most commonly used open source ones are Trac and Redmine.

Cloud based issue trackers include Lighthouse and GitHub.

Commercial solutions include Jira.

In this course, we’ll be using the GitHub issue tracker.

Anatomy of an issue#

There are three main pieces of information required when someone reports a bug:

  • How to reproduce

  • Expected outcome

  • Actual outcome

(Note how conceptually simular this is to the anatomy of a test)

There are other fields that can be useful within a software development team for prioritisation and tracking (but don’t ask an user to specify these):

  • Reporter

  • Description

  • Owner

  • Type [Bug, Feature]

  • Component

  • Status

  • Severity

Reporting a Bug#

The description should make the bug reproducible:

  • Version

  • Steps

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.


  • Submitted

  • Accepted

  • Underway

  • Blocked


  • Resolved

  • Will Not Fix

  • Not reproducible

  • Not a bug (working as intended)

Bug triage#

Some organisations use a severity matrix based on:

  • Severity [Wrong answer, crash, unusable, workaround, cosmetic…]

  • Frequency [All users, most users, some users…]

The backlog#

The list of all the bugs that need to be fixed or features that have been requested is called the “backlog”.

Development cycles#

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)

GitHub issues#

GitHub doesn’t have separate fields for status, component, severity etc. Instead, it just has labels, which you can create and delete.

See for example Jupyter