Skip to content

Latest commit

 

History

History
37 lines (29 loc) · 2.86 KB

CONTRIBUTING.md

File metadata and controls

37 lines (29 loc) · 2.86 KB
Raw

MDTP Contributor Guidelines

Hello!

Thank you for taking the time to contribute to the HMRC Multichannel Digital Tax Platform (MDTP). Please take a few minutes to review this process and guidelines before you submit your request, otherwise it may be rejected.

It is important to remember that an Issue and a Pull Request are a placeholder for a conversation between the Requestor and the Owning Team - people and interactions are more important than processes and tools. The Requestor should contact the Owning Team as soon as changes to the Repository are considered.

MDTP Contribution Process

This process applies to all repos in our organisation. Every microservice or library on the MDTP is looked after by a particular service team, allowing them to have full control over the functionality that is core to their service. The owning service team are responsible for reviewing and choosing to accept your PR.

  1. The Owning Team stands ready for Pull Requests and reserves some per-team capacity to monitor, review, and test Pull Requests
  2. The Requestor opens an Issue on the Repository and talks with the Owning Team about the proposed changes
  3. The Owning Team informs the Requestor:
    • If the proposed change is unnecessary i.e. if the Repository already supports the desired outcome
    • If the proposed change is undesirable e.g. rejected in the past from a different Requestor
    • If the proposed change can be reviewed and released into production in a timeline acceptable to both the Requestor and the Owning Team
  4. The Requestor: 5. Forks the Repository and makes the proposed changes - including new tests 5. Runs the Repository build locally and ensures all tests pass 6. Pushes their changes to their fork and raises a Pull Request against the Repository Issue
  5. The Owning Team reviews the Pull Request according to the following criteria:
    • Can the changes be compiled and tested?
    • Do the changes clearly indicate what they are trying to achieve?
    • Are the changes aligned with our coding standards and our architectural approach?
    • Are the changes compatible with other in-flight changes to the Repository?
    • Do the changes introduce any new operational concerns e.g. performance, security?
  6. The Owning Team accepts or rejects the Pull Request
  7. If rejected, the Requestor asks the Owning Team for feedback
  8. If accepted, the Owning Team merges the changes into the Repository and creates a new release

After the merge, it is the joint responsibility of the Requestor and the Owning Team to: * discuss the optimal timing of pre-production and production releases * validate the functional and operational impact once the release reaches pre-production and production

It is the responsibility of the Owning Team alone to deploy/schedule the release into the relevant pre-production and production environment(s).