To handle issue and project tracking we use JIRA, which currently offers several different Issue Types when creating new tickets.

The expectations arising from each Issue Type are outlined below.

Addition Workflows

These issue types outline additions to the code base, in the form of new features (use cases).

Issue Types Used:

• Wish / New Feature: a high-level non-technical description of desired business logic
• Requirement: a "discussion" ticket describing a new feature that needs more of its technical description fleshed out
• Epic: a high-level technical description of desired software functionality or infrastructure containing multiple Story tickets
  
  • Note: Epic issues do not get explicitly added to Sprint
• Story: a use case describing an example usage of a small piece of newly desired functionality

General Relationship:

1. A New Feature or Wish ticket is filed describing the new feature at a high-level without mandating any particular technical specifications
2. A Requirements ticket is created if we feel that we do not have enough information to break the feature down into small pieces of technical work
3. A Story ticket is filed from the information resulting from the Requirement discussion
   
   1. If multiple Story tickets encompass the work needed, these tickets are grouped under an over-arching Epic ticket

New Feature Workflow

Reporter:

• Management
• Developer

When a Wish or New Feature ticket is in the Active Sprint:

1. The ticket is marked IN PROGRESS and assigned to a developer, who conducts the meeting
2. The feature is broken down into a digestable number of enumerated use cases
3. If one or more use cases require more detail, a Requirement ticket is filed
4. The use cases are filed as Story tickets and associated to an Epic
5. The resulting Story tickets are then discussed at the next Sprint Planning meeting

Deliverables:

• New tickets describing the next steps necessary to enable the feature described

Outstanding questions:

• When do I use a wish over a new feature?
  • Are Wish tickets requested by people external to NCSA?
  • Does a New Feature have less detail than a Wish? Perhaps more detail?

Requirements Workflow

Reporter:

• Developer

When a Requirement ticket is in the Active Sprint:

1. The ticket is marked IN PROGRESS and assigned to a developer, who conducts the meeting
2. A meeting is created in Outlook to contact interested parties (i.e. NDS Labs Dev team, Nebula team, other NDS-affiliated software teams, etc.)
   1. The requirements are discussed with the development team and any interested parties
   2. Any information resulting from the discussion is filed into a Confluence wiki page
   3. The information from the Confluence page generates use cases
   4. If applicable, a new Epic is created to encompass the use cases presented
3. The use cases are filed as Story tickets and associated to an Epic
4. The ticket is marked IN REVIEW and assigned to another team member for review
   1. The reviewer may make any changes or comments that they desire and discuss with the team
5. The ticket is marked RESOLVED or CLOSED
6. The resulting Epic / Story tickets are then discussed at the next Sprint Planning meeting

Deliverables:

• A Confluence wiki page detailing the discussion held and the use cases generated from that discussion
• New Epic / Story tickets describing the steps necessary to enable the use cases described

Story Workflow

Reporter:

• Developer

When a Story ticket is in the Active Sprint:

1. The ticket is marked IN PROGRESS and assigned to a developer (referred to hereafter as "the developer")
2. The developer does the work necessary to enable the use case described in the ticket
   1. Follow the general development workflows defined above
3. Comment on the Story with links to any deliverables that should be reviewed / tested
4. The ticket is marked IN REVIEW and assigned to a tester (referred to hereafter as "the tester")
5. The tester reviews the deliverables of the Story:
   1. Review any related Pull Requests
   2. Review any Test Cases / Documentation provided
   3. Review any new tickets resulting from the work done
   4. Pull and run any new Docker images against the Test Cases provided
6. The tester selects Review Accepted and the ticket is marked as RESOLVED
7. The tester merges any outstanding Pull Requests related to this ticket
8. The developer switches back to their master branch and syncs with the new changes
9. If applicable, the developer builds and pushes a new "latest" Docker image for the API / UI incorporating the new changes
10. The developer selects CLOSE TICKET and the ticket is marked as CLOSED

Deliverables:

• Pull Request(s) to GitHub
• New Image(s) / Tag(s) in Docker Hub
• Test Case(s) demonstrating the use case fulfilled by the story
• Documentation describing the technical aspects of the solution

Alteration Workflows

Issue Types Used:

• Improvement: a suggestion to utilize new techniques or technologies to improve overall performance or maintainability of the platform

• Bug: a previously completed use case or edge case that is malfunctioning according to its defined behavior

General Relationship:

1. A Bug or Improvement ticket is filed detailing a potential modification that will have a positive impact on the platform
2. If necessary, a Requirement ticket is filed to explore the ramifications of the changes

Improvement Workflow

Bug Workflow

Accounting Workflows

Issue Types Used:

• Comment: track miscellaneous information / feedback / requests that do not match other issue types
• Processing Request: track the creation of new entities in production instance of NDS Labs
• Task: work that is not driven by a new use case. Contains zero or more Sub-Issue tickets
  • Technical Task: a small piece of technical work that is not driven by a new use case
  • Sub-Task: a small piece of outreach or non-technical work / discussion that is not driven by a new use case

General Relationship:

1. A Comment / Processing Request / Task ticket is filed to track work that must be tracked
   1. For these tasks, it is likely that you will not need to make any actual modifications to the code
2. Larger tickets can be broken up into a series of Technical Task and Sub-Task tickets
3. If necessary, a Requirement ticket is filed to explore the nature and limits of the support granted by this ticket

Comment Workflow

Reporter:

• Management
• External Contributor

Used to Track:

1. new sites / groups / contacts wishing to utilize the NDS Labs platform (i.e. Odum, TACC, SDSC, etc.)
2. similar technologies that we might look at for reference (i.e. JujuCharms, ProfitBricks, etc.)
3. new or existing technologies that might be leveraged to further NDS Labs
4. any other feedback-driven tasks that require explicit work to be done

Deliverables:

• If necessary, a Requirement ticket is filed to reflect on the meaning and validity of the comment

Request Workflow

Reporter:

• Management
• External Contributor

Used To Track:

1. projects (via Account Creation Workflow)
2. service specs (via Pull Requests made to ndslabs-specs)
3. any other process-driven tasks that require explicit work to be done

Deliverables:

• If necessary, a Requirement ticket is filed to discuss any further changes that might be necessary to process this request

Task Workflow

Reporter:

• Management

Used to Track:

1. events requiring special attention (i.e. hackathon, developer tutorial, etc.)
2. any other externally-driven tasks that require explicit work to be done

Deliverables:

• If necessary, a Requirement ticket is filed to determine any necessary hardware/software requirements prior to supporting the event