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, For Review, Done
- To Do: issues here should be adequately refined. If not, they should be removed from the sprint and placed onto the backlog. Tickets marked as prioritised should be done first, assuming you are confident that you have the technical knowledge to do so.
- In Progress: issues here have an assigned team member. Updates are added as milestones are reached. 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 placed onto the backlog.
- For Review: once the technical work is completed a summary is written and the issue is moved here. It will be compared to the definition of done by the reviewer then moved to done.
- 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/)
Sign your commits
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 CONTRIBUTING.md 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.

Spikes

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

Firebreaks

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 13 August 2024. It needs to be reviewed again on 13 February 2025 by the page owner #modernisation-platform .

This page was set to be reviewed before 13 February 2025 by the page owner #modernisation-platform. This might mean the content is out of date.