Page History

...

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
5. The reviewer may make any changes or comments that they desire and discuss with the team
6. The ticket is marked RESOLVED or CLOSED
7. The resulting Epic / Story tickets are then discussed at the next Sprint Planning meeting

...

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
   2. Comment on the Story with links / updates to any deliverables that
   should
   1. need to be reviewed / tested:
      1. Pull Requests
      2. Docker Images
      3. Documentation
3. The ticket is marked IN REVIEW and assigned to a tester (referred to hereafter as "the tester")
4. 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
5. The tester needs to Accept, Reject, or Abort the review based on the results
   1. If the ticket does not contain sufficient information to decide whether or not the deliverables are acceptable, then the tester
   selects Review Accepted and the
   1. selects Review Aborted
      1.  The ticket is marked as OPEN and work is stopped on the ticket
      2. The developer adds more detail to the ticket, for example:
         1. Test Case
         2. Passing Conditions
      3. The developer then returns to #2 above and refines their deliverables
   2. If the the deliverables are missing, incomplete, or in an untestable state, then the tester selects Review Rejected
      

      1. The ticket is marked as IN PROGRESS and should then be assigned back to the developer

      2. The developer then returns to #2 above and refines their deliverables
   3. If the deliverables are tested and in an acceptable form, then the tester selects Review Accepted
      1. The ticket is marked as RESOLVED
      2. The tester continues the workflow below
6. The tester merges any outstanding Pull Requests related to this ticket
7. The developer switches back to their master branch and syncs with the new changes
8. If applicable, the developer builds and pushes a new "latest" Docker image for the API / UI incorporating the new changes
9. The developer selects CLOSE TICKET and the ticket is marked as CLOSED

...

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

Improvement tickets follow a workflow that resembles that of a Story ticket

Reporter:

• Developer

When an Improvement ticket is in the Active Sprint:

Deliverables:

Bug Workflow

Reporter:

• Developer

When a Bug ticket is in the Active Sprint:

Deliverables:

Accounting Workflows

Issue Types Used:

...