RFC Process #770
Locked
DavidLawes
started this conversation in
Ideas
RFC Process
#770
Replies: 1 comment
-
|
@waisingyiu @frankie297 @groakland @petternitter |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Summary
We might like to introduce a process for planning, collaborating and agreeing larger architectural changes. Using an RFC (Request For Comments) process within github would help us achieve this, as well as improving the documentation and discoverability of our design changes.
EDIT: the team decided to trial this process and evaluate its effectiveness.
Need
During Q2 of 22/23 the Mobile Server Side team focussed on improving the speed of delivery of mobile push notifications. This was a challenge because large parts of the system were unfamiliar (at least to me!) and so the work took the form of:
The approach we took to deliver changes in Q2:
This quick, iterative approach enabled us to increase the speed of delivery for a large subset of notifications. However, there are still some use-cases that don't meet the SLO (Service Level Objective) of delivering a notification to 90% of the intended audience within 2 minutes.
Now we're approaching the end of Q2 and are thinking about what to do next, we believe that larger architectural changes will be required if we want to further improve the performance of push notification delivery.
The process of making these larger architectural changes should be different from how we've worked during Q2. It would be good to agree as a team how we can manage these changes, ensuring all stakeholders (our immediate team as well as more senior colleagues from across the business) have visibility of any proposals as well as enough information and time to engage and comment on them.
Approach
It's suggested that we use an RFC-like process to document our design ideas in order to collate feedback and reach a consensus on any design proposals.
It's important that we enable the wider team, as well as senior stakeholders from across the business, to engage and comment on our proposals. To achieve this the suggested process includes:
The person driving the process is the developer(s) raising the design proposal, as they will most likely be responsible for implementing it. It's suggested to use Github as much as possible during the process: co-locating the design proposals with the associated codebase will help increase the transparency and discoverability of the proposals for future colleagues.
After the developer(s) have adequately addressed all comments received the design is considered approved. After this point the developer(s) can begin to plan and implement the change.
After the change is implemented we could consider documenting the change as an Architectural Design Record, a .md file describing when and why we made the change - similar to the /docs/architecture files we've been creating in Q2.
This flow chart aims to capture the suggested process:
sequenceDiagram participant dev as MSS Developer participant github as Github Discussion participant team as MSS Team participant ext as Wider Stakeholders participant code as Codebase participant adr as Design Record dev ->> github: create new discussion note over dev, ext: Developer to schedule and host a meeting to introduce and explain the proposal dev ->> team: request comments and feedback dev ->> ext: request comments and feedback note over dev, ext: Indicate appropriate timeframe for comments to be received by team -X github: comments ext -X github: comments dev ->> github: review and address every comment dev ->> github: update proposals, if necessary note over github: given all comments satisfactorily addressed, design proposal is approved dev ->> code: plan and implement changes dev ->> adr: create a PR for the ADR (long-term record of the change)Beta Was this translation helpful? Give feedback.
All reactions