Here is a template for raising an issue, copy and paste it into the text field and fill it:

## Steps to reproduce



## Environment

Device:
Browser:
OS:
URL:

We welcome code submissions from other teams. Here's the rules of engagement.

• The philosophy here is about communication, taking responsibility for your changes, and fast, incremental delivery.
• Speak to the team before you decide to do anything major. We can probably help design the change to maximise it's chances of being accepted.
• We have three environments - DEV (your machine), CODE and PROD.
• Pull requests made to main assume the change is ready to be pushed in PROD (code, ux, design, qa).
• Many small requests will be reviewed/merged quicker than a giant lists of changes. Use a switch if you do not want the public to see what you are releasing (Eg, here and here).

This is applicable to GMG employees.

• Understand what you are trying to achieve with the change (what does success look like?)
• Fork the code and make your changes.
• Test your branch locally by running unit and integration tests:
  • ./sbt project <project> test
  • make test
• Open a pull request.
  • Explain why you are making this change in the pull request
  • Include information about how you plan to measure success (e.g. links to analytics reports)
  • If this change is not measurable be very clear about that fact.
• A member of the team will review the changes. Once they are satisfied they will approve the pull request.
• If there are no broken or ongoing builds in Teamcity, merge your branch and then ensure the main branch is built successfully: both builds and integration tests.
• Your build will continuously deploy straight to PROD
• Pay close attention to our monitoring.

Firstly, thanks for helping make our service better! Secondly, we'll try and make this as simple as possible.

• Fork the frontend project on GitHub, patch the code, and submit a pull request.
• We'll test, verify and merge your changes and then deploy the code.
• Certain contributions will require a Contributor License Agreement.

Here's some wise words from @gklopper.

We only merge to main when the software is ready to go live. This will be different for each thing we do, it might be as simple as showing the person next to you that the typo has been fixed, or you might spend an afternoon with Design or Dotcom Platform looking over your shoulder.

If in doubt ask the team, the team is your conscience.

Once deployed to PROD check that your software is doing what you expected.

If it is a bit late in the day or it is nearly lunch and you do not want to deploy to PROD immediately then do not merge to main.

After a few days it's polite to report back to the team how the feature is being used by the audience.