Page History

...

Improvement tickets follow a workflow that resembles that of a Story ticket, with some slight modifications.

Reporter:

• Developer
• External Contributor (via GitHub "enhancement" issue)

...

1. Ticket Status: Start Progress
2. Developer creates a new branch with a small prototype instance containing suggested improvement(s)
3. Developer weighs the pros / cons of this solution over the current one against the time it would take to fully implement and test the change
   1. If not desirable, the developer abandons the branch(es) containing these changes and marks the ticket as CLOSED
   2. If desirable, the developer completes the modifications
4. Developer creates any necessary deliverables
5. 1. on the branch
6. Once complete, developer gathers the necessary deliverables:
   
   1. Confluence: Create documentation and/or take note of technical details
   1. GitHub: Create Pull Request(s)
   2. DockerHub: Create and push a test image tagged with the name of the corresponding git branch
   3. ???: Create new / update existing test cases relating to the modifications
7. Ticket Status: Review Ticket and assign to Tester
8. Tester reviews / tests any deliverablesGitHub: Review Pull Request(s)
   • Confluence: Review any relevant documentation or technical details
   • GitHub: Review related Pull Request(s)
   • DockerHub:
   Release new "latest" stable Docker images of UI / API (if applicable)
   • Pull and run test image(s) against test cases
   • ???:
   New
   • Run any new / updated test cases
   resulting from
   • relating to the modifications
9. Tester merges any deliverables Pull Requests (if applicable)GitHub: Merge related Pull Requests (if applicable)
10. Ticket Status: Resolve Ticket and assign back to Developer
11. Developer releases other deliverables themselves
    
    1. Confluence: Migrate Developer migrates any relevant documentation from Personal Space to "National Data Service" public space (if applicable)
    2. GitHub + DockerHub: Developer syncs with upstream changes (if applicable)
    3. 1. git checkout master
       2. git pull upstream master
       3. git push origin master
    4. DockerHub: Developer builds and pushes elease new "latest" stable Docker images of UI / API
    5. GitHub: Developer commits and pushes new build date upstream (if applicable)
12. Ticket Status: Resolve / Close Ticket

Bug Workflow

Bug tickets follow a workflow that resembles that of a Story ticket, with some slight modifications.

Reporter:

• Developer
• External Contributor (via GitHub "bug" issue)

...

1. Ticket Status: Start Progress
   1. aside: consider creating a new status for "Verification" stage of Bug tickets?
2. Developer reviews affected Use Case(s) and verifies behavioral divergence
   1. Developer examines validity and may suggest modifications to the Use Case
   2. Developer determines where the bug stems from in the source
   3. Developer devises one or more ways to address the bug in question
   4. Developer selects the "best" option according to their judgement given the circumstances
3. Developer developer fixes product behavior to match expected Use Case
4. Once complete, developer gathers any necessary deliverables:
   1. Confluence: Create documentation and/or take note of technical details
   2. GitHub: Create Pull Request(Rarely) modify Use Case to match behavior
5. Developer creates any necessary deliverables
6. 1. s)
   2. DockerHub: Create and push a test image tagged with the name of the corresponding git branch
   3. ???: Create new / update existing test cases relating to the modifications
7. Ticket Status: Review Ticket and assign to Tester
8. Tester reviews / tests any deliverables
   1. Confluence: Review any relevant documentation or technical details
   1. GitHub: Review related Pull Request(s)
   2. DockerHub: Pull and run test image(s) against test cases
   3. ???: Run any new / updated test cases relating to the modifications
9. Tester merges any Pull Merge any deliverables (if applicable)GitHub: Merge related Pull Requests (if applicable)
10. Ticket Status: Resolve Ticket and assign back to Developer
11. Developer releases other deliverables themselves
    
    1. Confluence: Migrate Developer migrates any relevant documentation from Personal Space to "National Data Service" public space (if applicable)
    2. GitHub: Developer first syncs with upstream changes (if applicable)
       1. git checkout master
       2. git pull upstream master
       3. git push origin master
    3. DockerHub: Release  Developer builds and pushes new "latest" stable Docker images of UI / API
    4. GitHub: Developer commits and pushes new build date upstream (if applicable)???: New / updated test cases that match expected behavior
12. Ticket Status: Resolve / Close Ticket

Accounting Workflows

...

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

When a Comment ticket is in the Active Sprint:

• Do these issues get added to sprint?

Request Workflow

Reporter:

...

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

When a Processing Request ticket is in the Active Sprint:

• Do these Issues get added to Sprint?

Task Workflow

Reporter:

• Management
• Developer

...

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

When a Task / Sub-Task / Technical Task ticket is in the Active Sprint:

• Do these Issues get added to Sprint?