Bugs are the highest priority Tickets. Bug reports go into the top of "ready to-do" column on the Kanban and use the default issue template.
Bugs have the highest priority and go straight into the top of "ready" and follow the following process:
If a bug needs further clarification, keep it at the top of "ready", but ask questions and move on the next ticket. When you come back for your next ticket, check the bug until clarified.
When catching a bug cast a wide net. Could better software design have prevented the bug? If so, create an additional
tech-debt ticket that describes the improved design and place it at the top of "clarify".
Follow the 'campfire rule' -- don't just fix the bug. Leave the code in a better state than when you found it. Refactoring for clarity and improving test and type checking coverage
Please describe the behavior you are expecting
What is the current behavior?
Please help provide information about the failure if this is a bug. If it is not a bug, please remove the rest of this template.
Please provide detailed steps for reproducing the issue.
you get it...
Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.
Please include any relevant log snippets or files here.
This section documents the process of how our development team resolves bug reports.
Despite being in "ready" a bug may need clarification. If so, keep the ticket at the top of "ready", but ask questions and move on the next ticket.
When you come back for your next ticket, check the bug ticket until clarified.
Visit staging and attempt to reproduce the bug. If you can't reproduce the bug shift staging into "staging" and tag the orignal bug finder If you can reproduce the bug proceed to to step 2.
Assign yourself to the ticket and shift to "in-progress".
Why did the bug occur? Cast a wide net and think about. Does the bug point to larger issue? Perhaps the data structures are forcing developers to write workarounds.If so, make technical debt ticket. Proceed to step 3.
Most bugs will fall into one or more of the following categories:
"database / API"
"interaction" / "styling"
A critical path bug compromisese the core functionality of the app. For example we encountered a bug on the assessment submission form where the user was not redirected the submitted page. These bugs correspond to acceptance tests -
Its possible that a database function or API call has incorrect logic or does not account for a particular case. The bugs correspond to integration or database unit tests -
The bug may stem from incorrect logic or unhandled cases in an isolated function call. These bugs correspond to unit tests -
if the bug cuts across several categories (for example, UI and critical path) it may need to be broken up into several tickets.
From the previous step we now understand the nature of the bug and the kind of tests we need
Commit your code and push to a branch
If you have multiple tests proceed from the smallest piece first, (eg. unit)
Once all tests pass and the code has been improved and type checked you may:
squash all commits and push to your bug branch.
open a pull request from the bug branch into
At this point the CI will run all integration and unit tests. If CI tests pass you may merge your pull request into
dev and proceed to Step 8. If CI tests fail proceed to Step 7b.
Inspect the test logs in the CI and triage the error. If the error is obvious fix and proceed to step 7a. If the error is mysterious @mention another developer.
Visit the freshly deployed app on the dev server and attempt to reproduce the bug. If you cannot reproduce the bug and proceed to step 9. @mention the original bug finder asking them confirm the bug has been resolved.
Pull the latest
dev and merge into
master locally on your own machine. Conduct Step 4 - Tests.