Page History

...

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 need to be reviewed / tested:
      1. Pull Requests
      2. Docker Images
      3. Documentation
      4. New JIRA Tickets
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 JIRA 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 Aborted
      1.  The ticket is marked as OPEN and work is stopped on the ticket
      2. The developer adds more detail to the ticket before continuing, for example:
         1. Test Case
         2. Passing Conditions
      3. The developer then returns to #2 #1 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 #1 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 master and syncs with upstream (to pull the new changes into their master branch)
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

...