Issue Workflow - acquaman/acquaman GitHub Wiki

The following page details the life-cycle of a GitHub issue and how it ideally moves through the Boards provided by ZenHub. In general, an issue will start in New Issues and will always move to right along the board until it finally ends in Closed. Although there are always exceptions, the general path an issue should take is New Issues, Backlog, To Do, In Progress, Closed. All the pipelines will be outlined on their intended function and how issues move in and out below.

New Issues

Function: Holds all issues that have been newly created and have not been assigned a complexity estimate.

Issues only enter this pipeline when they are newly created.
Issues can move into the following three pipelines:

  1. Backlog (standard): After being assigned an estimate the issue will be moved into this pipeline.
  2. Requires Investigation: If there is not enough information to assign an estimate to the issue it is given the Requires Investigation tag and moved into this pipeline.
  3. To Do: For the event that an issue needs to be worked on immediately. These issues are also given the Hot Fix label.

Requires Investigation

Function: Holds the issues that were not assigned an estimate due to lack of details or unknown scope. Once more information is known about the issue it will be assigned an estimate and continue to follow the normal issue workflow. All issues in this pipeline should have the label Requires Investigation.

Backlog

Function: Holds all issues that have been assigned an estimate and are not considered a high priority. If issues should be worked on, they are a part of the To Do pipeline.

Issues move into this pipeline immediately after being assigned an estimate by the team.
Issues will typically leave this pipeline when those issues are considered a priority and should be added to the To Do pipeline.

To Do

Function: Holds all issues that should be worked on by the team based on project milestones, important bug fixes ,or feature requests. All issues inside the pipeline will have an assigned estimate where developers will have an expectation of the difficulty of the issue before tackling it.

Issues move into this pipeline when their priority shifts such that they should be worked on in the short term.
Issues move out of this pipeline when a developer takes ownership of the issue to work on and assigns themselves to the issue (via GitHub).

Note: There should be no issues with a complexity of 13, 21, or 40 in this pipeline. Those issues have been deemed to complicated and should be split up into smaller issues of complexity 1, 2, 3, 5, 8 so that no one gets stuck working on issues for weeks on end.

In Progress

Function: Holds all issues currently being worked on by the team. This list should be rather short as each developer should typically only have one issue assigned to them at any given moment.

Issues move into this pipeline when a developer assigns themselves to the issue and being working on the task.
Issues can move out of the pipeline in one of two ways:

  1. The task is completed. Once completed, the developer adds a comment to the issue with a line Time Estimate: X minutes/hours/days.
  2. The task is stalled due to lack of access to proper testing. In this case, the issue is moved into the Testing pipeline until such a time that testing can be completed.

Testing

Function: This holds all issues stalled due to lack of access to proper testing. It provides at a glance knowledge of all issues that may be languishing because the developer can not perform all necessary testing to ensure correct behaviour.

Issues move into this pipeline if testing is the main hold up for the issue (i.e.: no major development is required aside from changes brought to light by testing).
Issues leave the pipeline once the task is completed. Once completed, the developer adds a comment to the issue with a line Time Estimate: X minutes/hours/days.

Closed

Function: Holds all completed issues. Issues that move here will be retrospected to redo the complexity analysis to take into account how difficult the task ended up being. Assuming the issue has been completed via normal means it should contain the following pieces of information:

  • Complexity estimate.
  • A time estimate on how long it took to complete in the style of Time Estimate: X minutes/hours/days.
  • An actual complexity to close the loop on the issue.

Issues can enter this pipeline any time they are closed. If the issue is closed by not following any of the processes outlined above, then the label Project Tracking Disabled must be added.