Skip to main content

Our ways of working

Team Availability and Support

  • Maintain a minimum of two engineers per sprint
  • Provide notice for leave (generally twice the leave period)
  • Operate a duty rota for #ask-modernisation-platform channel support

On-Call Support

  • Only during listed hours
    • 7AM-9AM and 4PM-10PM weekdays
    • 7AM-10PM weekends and bank holidays
  • Must be working as DevOps engineer or above
  • Must have passed their probationary period
  • Members require sufficient experience
  • Opt-in basis for rota

Work and Task Management

  • GitHub projects are used to manage our workload
  • Work in two-week sprints
  • Longer term objectives tracked in team roadmap.
  • Ensure tasks meet Definition of Ready (DoR) before sprint planning
  • Backlog issues are adequately refined by the team
  • Issues in sprint can be: To Do, In Progress, Blocked, Done
    • To Do: issues here should be adequately refined. If not, they should be removed from the sprint and placed onto the backlog.
    • In Progress: issues here have an assigned team member. Updates are added as milestones are reach. Links to PRs and other useful information should be included.
    • Blocked: issues here have external dependencies preventing their progress. Issues we expect to be blocked for the duration of a sprint should be place onto the backlog.
    • Done: issues here have been implemented, tested, and reviewed.
  • When an issues is Done it should be closed

Git and GitHub Practices

  • Maintain good git hygiene (fetch/pull before branching, regular merging, squashing extensive commit lists)
  • Use meaningful branch naming (e.g., feature/, fix/, docs/)
  • Write meaningful commit messages
  • Verify tests and pipeline completion before raising PRs
  • Provide clear PR descriptions with context
  • Review PRs thoroughly, approving only those you understand
  • Use GitHub PR for discussion of content, rather than Slack
  • Follow Semver for versioning
    • Provide a high-level What's New in the version release notes
    • Make use of GitHub’s automatically generated release notes feature
    • Optionally trim the release notes down to commits affecting consumers

Contributing to Modernisation Platform Modules

We work in the open, and welcome contributions to our code. Anyone is welcome to submit fixes, features, or enhancements to our repositories where we maintain a standard document.

Review criteria

  • Ensure builds are error-free
  • Maintain backwards compatibility for new features
  • Test thoroughly when amending existing features
  • Add tests for new features
  • Discuss reasons for removing features
  • If in any doubt, speak to team colleagues for assistance.

Change Management

Some changes to our platform are safe to roll out at any point once they are reviewed and approved. Others need more caution and require communicating to our tenants and sometimes need actioning. The following table is to class the changes and to describe the process of communicating such changes.

Change Classification Change Characteristics Rollout Process
No communication needed These are changes that do not require an outage and can be safely deployed with no impact on users No action needed
Needs communicating, but no action and no notice needed These are changes that add new features or enhance new features, but do not change the existing fundamental behaviour of the platform Use the ask and update channels to communicate it and keep the announcement neutral. The information should include what is changing (e.g. which service or feature) and its impact
Needs communicating in advance These are changes that are not backwards compatible and/or require an outage (some or all platform’s feature will not be accessible at the time of the changes deployment). In other words, these are changes of which deployment causes a temporary loss of service or access. Agree within the team on the notice period prior to the update rollout. Post on the status page about the planned maintenance. This will automatically post in the ask and update channels. The information should include what is changing, its impact and how long it will take to roll it out. Post a reminder in our channels closer to the scheduled outage.
Requires user action These are changes that are not backwards compatible and require user’s input to be completed (e.g. changes to platform files in the modernisation-platform-environments repository require deploying to users environments). Agree within the team on the deprecation period. Once the changes are rolled out, communicate it in the ask and update channels. The information should include what is changing, its impact and how long is the deprecation period. During the deprecation period post reminders in the ask and update channels if not all users have actioned. When the deprecation period expires, reach out to users via email using the infrastructure-support contact information from the environment files. Making sure that all users have updated is part of the issue’s DoD.


  • Timeboxed research tasks (maximum length one sprint)
  • Use SPIKE: prefix in issue title
  • Document findings and present to team
  • Create follow-up issues if proceeding
  • Create Architectural Decision Record if outcome is of architectural significance


  • Opportunities for platform improvements
  • Backlog issues with firebreak label
  • Schedule team firebreak sprint when sufficient issues accumulate
  • Current stock of labelled issues here
This page was last reviewed on 19 July 2024. It needs to be reviewed again on 19 January 2025 by the page owner #modernisation-platform .
This page was set to be reviewed before 19 January 2025 by the page owner #modernisation-platform. This might mean the content is out of date.