Background

In the fall of 2016 the CASA development group (CDG) migrated to a new JIRA server that is integrated with Atlassian software systems Confluence, BitBucket, and Bamboo. This change is motivated by the recommendations provided by an exernal consultant who studied the CDG in 2015. The Data Management and Software Department (DMSD) has developed a software development processes document that describes departmental policies and recommendations for its software teams; this document adopts some of the recommendations applicable across the department. The CDG JIRA processes follow the DMSD processes as much as possible. This document describes these processes.

Issue Types

The following table describes the issue types allowed in the CASA project:

Issue Type	Description
Bug	A request to correct a deviation of the system from its specified behavior.
Feature	A request to change the current specified behavior.  Features should always undergo validation testing.
Engineering Task	An internal change request to improve maintainability of the code, perform refactoring activities, clean up, improve documentation, etc.  An issue of this type does not require validation (user) testing.
Epic	A large, cross functional work request that requires substantially more coordination than other jobs.
Research Request	A request for new capabilities in which either the requestor cannot define the expected result or the developers are unsure about whether the requirement can be implemented.
Sub-Task	Part of a larger issue.

For a brief description of JIRA issue types see the JIRA Concepts - Issues page. All of the issue types allowed in the CASA project are described in detail in the DMSD software development processes document. The only exception is the Sub-task issue type, which has been turned on for the CASA project to allow other issues to be broken down into smaller work assignments. The sub-task issue type uses the Feature workflow.

Note on Features vs. Epics

Features and Epics are described in the DMSD document in sections 7.2 and 7.4, respectively. A Feature has low coordination needs and is a relatively small, compact change. If the implementation requires coordination or will take more than two weeks to develop, the request should be characterized as an Epic. Epics are typically broken down into sub-tasks.

Issue States

The following table describes the issue states allowed in the CASA project:

Issue state	Description	Responsible
Open Initial state after a new ticket is created.">Open	Initial state after a new ticket is created.	Component lead
Unscheduled Ticket has been accepted but has not been scheduled yet.">Unscheduled	Ticket has been accepted but has not been scheduled yet.	Developer
Input Required Ticket requires additional information.">Input Required	Ticket requires additional information.	Domain expert
Scheduled Ticket is investigated, reproduced, fixed, and tested.">Scheduled	Ticket is investigated, reproduced, fixed, and tested.	Developer
Ready to Verify Ticket requires additional verification besides that executed by the developer while in the Scheduled state.">Ready to Verify	Ticket requires additional verification besides that executed by the developer while in the Scheduled state.	PM / GL
Under Verification Additional verification tests are executed and results reported.">Under Verification	Additional verification tests are executed and results reported.	Verification tester
Ready to Validate Waiting state where ticket is ready to be tested by Validator.">Ready to Validate	Waiting state where ticket is ready to be tested by Validator.	Validation lead
Under Validation Validation test is performed.">Under Validation	Validation test is performed.	Validation tester
Resolved Developer performs post-development activities, such as merging to the final branch, etc.">Resolved	Developer performs post-development activities, including making a pull-request.	Developer
Resolved Developer performs post-development activities, such as merging to the final branch, etc.">Completed Ticket is ready for delivery but has not yet been delivered.">Completed	Ticket is ready for delivery but has not yet been delivered.	Build Team
Closed Final state. No more work can be done.">Closed	Final state. No more work can be done.	None

The issue states are described in greater detail in the DMSD software development processes document.  

Under normal conditions an issue cannot be reopened. The reason for this restriction lies in the way that the JIRA issue workflow is integrated with the revision control system (BitBucket). After development activity, an issue is closed when the branch associated with the issue has been merged back into the master branch. Since there is no way to unmerge a branch, there is likewise no way to un-close a ticket. Rather than re-opening a ticket, you must create a new ticket.  In exceptional circumstances (such as human error) a CASA project administrator can reopen a closed ticket.

Issue Workflows

Each issue type has its own workflow describing the issue states allowed and the allowed transitions between states.  We have attempted, as much as possible, to minimize the number of clicks required to move an issue through the workflow.  The table below describes the workflows for each issue type:

Issue Types	Workflow Description
Bug Feature Epic Sub-Task	The workflows for these issues contain all states described above.
Engineering Task	Workflow does not contain validation steps.
Research Request	Workflow does not contain verification or validation steps.

A graphical rendering of the Bug / Feature / Epic / Sub-Task workflow is shown, below:

When viewing a JIRA ticket, a link is available next to the issue status value, "View Workflow". If you click this link you will see a graphical description of the workflow for that issue type. The graphical workflow includes tool-tips that describe each status and transition. For a more detailed discussion of workflows see the DMSD software development processes document.