Decision on Code Submission Process now we're working in separate Product Teams

Background

1. We created a process for approvals of PRs when working as one super-team

2. We largely followed it

3. Git now offers other out of the box things we can do

4. We're now working as (currently) two Product Teams (ultimately three or more)

5. We have now been fully following the originally outlined process

Flow Chart of the new process

Open

Comments on the diagram

• The diagram presents and an example of the cross team review process which would conversely apply in situations where the Admin Team wanted to make changes to a product owned by the Trainee Team.

• The team that wants to make changes to a product not owned by them are responsible for creating, refining and managing tickets through their lifecycle.

• At least one member of the owner product team needs to review the code changes in the pull request, in addition to a developer from the team undertaking the changes.

• It is the responsibility of the team that undertake the code changes to fix any bugs and code smells identified.

• Once changes have been approved, the team undertaking the changes are responsible for deploying the code to pre-prod and prod as well as fixing any errors identified in testing

• Circumstances where the code changes are rejected by the product owners and the pull request is declined are considered edge cases and it is suggested that the original ticket is reviewed by both teams to agree next steps. If such scenarios become more frequent, it may be necessary to refine tickets jointly before being flagged as ready for development

• Changes that impact both team, such as changes to infrastructure require joint refinement of the ticket and approval of the pull request.

Action items