Skip to content

Introduce RFC as a Technical Standard to Manage Change #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
LBHSPreston wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Introduce RFC as a Technical Standard to Manage Change #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions rfc-002-using-rfcs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
---
status: proposed
---

Comment on lines +1 to +4
Copy link
Contributor

@spikeheap spikeheap Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
---
status: proposed
---

This was a mistake on my part. Adding the status means it ends up in the repository still saying proposed, or it needs to say accepted in the PR, which doesn't feel like it makes any sense either 🤷 .

I suggest we delete that bit from the template and just say anything in main is accepted, while anything in a branch is proposed.

We can deal with edge cases like revoking decisions if we ever end up with that complexity

# Must Use RFCs for Architectural or Process or Technical Operational Changes

## Summary
All changes to our current architecture, processes, or ways of working must be covered by a Request for Change (RFC) for better governance and audit purposes.

## Problem
At the implementation of our initial Hack-It restructure, one of the decisions made was to eliminate the use of the Change Advisory Board (CAB) as it was felt that this was no longer fit for purpose. The majority of our projects were in a more agile format with delivery occuring once or more per week.

At the start of the Modern Tools for Housing programme, Architecture Decision Records (ADRs) were used to record decisions on changes to the architecture being built [ADR Repository](https://github.com/LBHackney-IT/lbh-adrs). These have not been used since the base API Platform architecture was established so for much of the changes since then, there was not a consistent way of recording decisions on changes so no clear audit trail.


## Proposal
In order to establish a clear audit trail and decision log for changes to what we build or how we build a record of decisions must be re-introduced. This is to be in the form of a Request for Change (RFC) which would give a broader scope on the types of change that could be recorded.
Any change to architecture patterns, engineering processes or technical ways of working should be backed by an RFC. The template RFC can be found at [RFC Template](https://github.com/LBHackney-IT/lbh-rfcs/blob/main/rfc-000-template.md).

## Scope
- Changes to architecture such as database technologies, encryption methods, etc.
- Changes to programming patterns such as Event Driven Architecture
- Changes to a feature or implementation for a serfice that has moved from development to BAU.
Copy link

@stonest stonest Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Changes to a feature or implementation for a serfice that has moved from development to BAU.
- Changes to a feature or implementation for a service that has moved from development to BAU.


## Out of Scope
- Products under active development and not in BAU (unless the change relates to the overall architecture or change in development standard).
- Emergency fixes (a retrospective RFC can be provided in these cases)