Date Last Updated: 15.06.18
This file outlines common default principles to govern how the team will use GitHub to organise its own workflow. This is to ensure that:
Current team members are clear on one common workflow.
We are able to easily on-board new starters with these introductory principles to team-working.
Stakeholders are able to easily track progression of the project.
- We will prioritise reviewing Pull Requests (PRs) over beginning new issues.
- Where possible, issues will include a user story and product requirements/acceptance criteria as well as links to relevant designs.
- Where possible, issues will be grouped together according to the product feature they relate to.
- After two days' effort, an assignee will add a comment to an issue and/or consider raising new issues to clearly indicate progress.
- When feedback is required, an assignee will open a PR with the 'WIP' prefix. See this ADR.
- As we facilitate deployment on a per-branch basis, once a PR is merged it is considered 'Done'.
- If a feature can reasonably be tested using an existing end-to-end test, this will be undertaken before the PR is approved. Any further or additional end-to-end testing will be raised in a new issue with the 'e2e test' label and referencing the original issue.
- An issue will never be re-opened, unless closed in error.