Effective Ticketing & the Definition of Done

Jackson Hoffart

Rule of Thumb

A good ticket should umambiguously transfer as much relevant context from your brain onto the ticket in the simplest and most concise way possible.

Title should clearly specify the output, rather than a vague description of the task:
- e.g. “User can reset their password” is better than “Improve authentication”
Use labels (e.g. feature, bug, BREAKING CHANGE, documentation, style, refactor, test, etc.)

For features, try to include a user story:
- e.g. “As a registered user, I might forget my password and want to regain access to my account securely.”
When possible, supplement the user story with unambiguous acceptance criteria

For bugs, be as detailed as possible!
- Often the limiting factor for fixing a bug is reproducing it.
For example:
- Environment setup (OS, browser, app version, etc.)
- Reproduction Steps (What precise actions lead to the bug?)
- Expected behaviour (What should have happened?)
- Actual behaviour (What actually happened?)
- Screenshots, logs, etc.

What must be true for the issue to be considered complete?
- Written as bullet points
- Example

Branching naming conventions:
- Feature branches should have their corresponding ticket number prepended
- E.g. if I am closing GH issue #14, I might call the branch 14-add_api_key_authentication
- This isn’t always relevant, especially with Monday tickets, however will be relevant again once we use Jira

brew install gh  # macOS
``

### Authenticating
``
gh auth login
``

### Cloning a Repo
```sh
gh repo clone RMI/web-api-poc

gh pr checkout 14

Questions?