Use an Issue Tracking System for All Problems

Summary

All problems should be handled by an issue tracking system.  Each issue should have a detailed description about how to reproduce the problem, and a short, complete, and compilable or runnable example.  Our debugging work should be scheduled based on the priority and severity of each issue.  Our progress in handling the issues should be documented by the issue tracking system.  

Based on ISO-24765-2010, a fault, also known as a defect or bug, is "an incorrect step, process, or data definition in a computer program."  And a failure that results when a fault is encountered, is defined as "an event in which a system or system component does not perform a required function within specified limits."  A problem can either be a fault, which is a problem in the code, or a failure, which is a reproducible problem.  Routines are callable units of code, which include member functions, methods, functions, procedures, and subroutines.

When setting out to fix a problem, choose the most appropriate strategy to succeed with less effort.  If it doesn't work, choose the next most appropriate.  

GitHub and GitLab provide basic issue tracking functionalities in their systems.  Other open source options include: Bugzilla, Launchpad, OTRS, Redmine, or Trac.  Such systems must be used to file all problems because:

* they provide visibility to debugging efforts

* they enable the tracking and planning of releases

* they facilitate prioritisation of work items

* they help document common problems and solutions

* they ensure that no problems will be missed

* they allow automatic generation of release notes

* they serve as repositories for measuring, reflecting on, and learning from these defects

Problems not recorded in these systems as issues should not be handled.  Some organisations do not permit changes to source code, unless the change is associated with an issue.  Each issue should have a detailed description of how to reproduce it.  Ideally, a short, complete, and compilable or runnable example should be provided in the issue description.  Each issue or bug report should also have a precise title, details about the bug's priority and severity, a list of the affected stakeholders, and essentials about its environment configuration or situation.  We should also document our progress in handling the issues by appending comments to each issue entry in the issue tracking system we use.  To ensure transparency, all steps taken to investigate and fix the bug should be recorded, including dead ends and the precise commands to log or trace the program's behaviour.  

Reference:

Diomidis Spinellis, "Effective Debugging: 66 Specific Ways to Debug Software and Systems"