Development

Comms

• We use Slack for day to day comms

• Our tickets are being migrated (March 2017) into Github, and can be viewed on the specific project in Github or in Waffle.

• We have 2x weekly standups and bi-weekly sprint planning.

Tickets

• We are learning the right scoping process for our tickets. As a start, please include who, what and why in tickets and issues, and as possible focus on user stories so that tickets include some user-facing result.

Branch structure, naming and other norms

• When a project has a api repo and a corresponding ui repo, if you are making changes in both, sync names between them.

• We use master as the main trunk from which branches should be made and pull requests submitted to.

• Use feature/feature-name and bug/issue naming for branches

• Feel free to submit WIP (work-in-progress) branches as pull requests if you desire feedback. Naming them with WIP will indicate they are not to be merged.

Code review

• For each ticket, use a pull request when it's ready to have someone else look at the code.

• This ensures we have two sets of eyes on each contribution so that multiple people are familiar with new code being added.

• As appropriate ask someone who didn't write the code to do a UI/useabilty review

Tests

• Ideally a different person than the primary writer of a feature should write the corresponding test