Change management ideas

Limit updates to times outside 8 AM - 12 PM and 1 PM to 5 PM
Perform incremental updates in small windows, rather than bundling many changes into a single window
Avoid a situation where we are "afraid" of making changes and then get into a situation where we avoid making changes and fall behind
Try to find a minimal window of exclusion for incremental updates
Service Windows / SLA
Resource: Google SRE (DevOps book). SLA is the contractual (service level agreement) whereas SLO (service level objectives)
Users can become accustomed to long periods of stability, so we must build regular downtime and maintenance into our operating procedures to manage user expectations
We don't have to "force" downtimes, but having something like quarterly downtimes scheduled in advance and at known days/hours enables us to

manage user expectations
give us breathing room to fix issues without needing to communicate in advance (other than a periodic, scheduled reminder)
allow us to give positive news when downtime is unexpectedly not needed, instead of negative news when it IS unexpectedly needed

We can communicate this with an SLO page on our RF docs

Build an issue in RF docs to start this

Start by reviewing the existing RF docs and the Google SRE resource named in the issue. Clarify the proposed maintenance windows, SLA/SLO terminology, and communication approach with maintainers. Done means an agreed SLO page or documented plan exists in the RF docs.