JIRA Use Conventions & Workflow

Introduction

Based on an e-mail from Jeff on 5/30/14 to the casa-staff mailing list.

The JIRA configuration has been tailored to better suit the CASA team's needs. Changes include:

• Revised issue types and definitions. (Removing infrequently used or redundant types.)
• New Issue resolutions (To distinguish between issues which are not bugs vs ones that won't be fixed.)
• Workflow states (To implement testing states and distinguish between scheduled vs. unscheduled tasks.)
• Workflow screens (Only display fields pertinent to the state change.)

These changes should also improve our ability to assess progress and status through JIRA. (for the CASA team, CASA mgt., NRAO mgt., etc.)

• Clearer indication of planned work for a cycle.
• Clearer indication of the status of planned work for a cycle and progress towards the release.
• Clearer indication of changes to the baseline (planned work) for a cycle.
• Improved tracking of build contents (connection between build system, VCS (SVN), and JIRA.)

This page is intended to define the ticket types, and their general workflow, states, and resolutions.

JIRA Ticket Types

The CASA project will support four primary ticket types in JIRA:

• New Feature: These are larger pieces of work that end with new features being delivered to our users (or to ourselves). These in general require some form of user validation at the end of the development (even if it’s just making sure we didn’t break anything). This validation can be internal to the CASA team for features we request ourselves.

• Task: Work that the end users may not notice, but needs to be done. These usually do not require user validation, regression testing for verification and ensuring that we didn’t break anything should be sufficient.

• Bug: An identified defect where the code does not work as intended or desired.

• Sub Task: to allow for multiple tasks within a Task or New Feature for the sake of organization and granularity.

General CASA Workflow

New Features & Tasks

New features and tasks will be scheduled as part of our release planning and Jeff will mark the Fix Version with the appropriate release. Sometimes small feature requests come in that are easier to just deal with than go through the process of waiting for them to be scheduled. In this case, the development team member may transition the Open ticket to Scheduled, marking the Fix Version field with the release they expect the change to be in. Jeff will routinely go through and do a triage of open feature requests and either place them on hold (to be scheduled later) or discuss with the relevant team member(s) where they fit in the schedule.

Some feature requests that come in are actually bugs (feel free to just change their Type) or are part of a larger feature that we already know about. In this case we should do one of two things:

• Link the ticket as a sub-task of the larger feature, and it will get done as part of that.
• Close the ticket, linking to the other feature ticket.

Which of these is chosen is entirely up to personal preference by the developer/scientist responsible for that piece of the code base (and if there is anything useful in the new ticket such as examples, or use cases you want to preserve).

Bugs

It is a project goal to have every bug ticket end up in one of the following states within 2 weeks of its submission:

• Closed as Fixed, Won’t Fix, or Not a Bug: Please mark the Fix Version field with the version that the bug fix will be delivered in. Please also note the JIRA ticket number in your SVN change log with your commit. Both these steps aid in tracking changes for testing and in developing a change log for the next release.
• Promoted to a feature request, and handled through the workflow described above, or linked to a feature request.
• Scheduled: If you think that this is a ticket that you can and should address either in the current cycle or in the next cycle just mark the Fix Version appropriately and then get to it when you can.
• Unscheduled: With a message that we agree this is a bug, but have not currently scheduled time to address it. This then gives the user a chance to argue their case (to Jeff) that this is really a priority.
• Reassigned to the person who really should be dealing with it, who then should get it into one of the states above.

JIRA Ticket Workflow (All Ticket Types)

Consistent with the general workflow described above, the workflow for an individual ticket, within JIRA has been implemented as follows:

Note: The On Hold state will be renamed to Unscheduled during final roll-out.

All new tickets will be received and placed in the Open state. The development team member should transition them to the Scheduled, Unscheduled or Input Required states as appropriate, with the latter being used to indicate that Jeff / CASA management should weigh in on the priority of the request, or that further information is required to address the ticket. The ticket should be in one of these states within two weeks.

CASA management will try to move tickets from Input Required to Scheduled or On Hold / Unscheduled within an equivalent two week period.

Tickets being worked on, or planned to be worked on during the current cycle, should be in the Scheduled state and eventually transition to the Resolved state. Bugs and Tasks that do not require user testing can be resolved directly. The Ready To Test state should be used to request user validation only, since verification testing is automatic using the automated regression suite. The Under Test state will be used by the Build & Test group to track current user testing assignments.

Transitioning tasks from Resolved to Closed should generally occur after the changes have been delivered to users/ticket reporters in a release or stable package.

Ticket Resolutions

Ticket resolutions available in JIRA have been expanded:

• Fixed: (Default) A fix for this issue is checked into the code tree and tested.
• Duplicate: The problem is a duplicate of an existing issue.
• Cannot Reproduce: All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behavior would occur. If more information appears later, please reopen the issue.
• Incomplete: The problem is not completely described and the reporter is unavailable to provide the needed input. (Typically only applicable to older tickets and occasional user reported bugs)
• Not a Bug: (New) The problem is not in the software package (E.g., user error.)
• Won't Fix: The problem described is acknowledged, but will not be fixed (due to available manpower, architectural limitations, design choices, conflicting/overriding needs, etc.)