Improve awareness of Required Upgrade Stops
What is this about
Introducing Upgrade Required Stops impacts the user experience critically. These are some pain points in the process:
- When we fail to either communicate, identify or implement an Upgrade Stop, if the developer and reviewers do not identify that a certain change would require an upgrade stop, it can break users upgrade, which leads to a lot of negative points. Like: user is unhappy, support can get overloaded with requests, the dev escalation might be triggered, issue can be escalated to the feature owner, etc. So a lot of hours wasted.
- Not everyone is aware of the importance of required stops, what they are, how/when to add them.
Related work
Automate upgrade stop and upgrade planning process (&12542)
Some proposals
From @plu8:
There are Adding required stops and Avoiding required stops pages currently, is it possible to consolidate both as a SSoT?
Both pages cover scenarios could cause upgrade stop, what I observed during the 16.x upgrade stop planning, engineers are often unclear with:
What kind of change has to be done in an upgrade stop?
What kind of change has to be done after an upgrade stop?
What our bots could help as part of automation?
From @Alexand:
Maybe tweaking https://docs.gitlab.com/ee/development/development_processes.html by moving "Avoiding required stops" link from "Complementary reads" to "Must-reads". In the "Avoiding required stops" we already have a link how to how add them under https://docs.gitlab.com/ee/development/avoiding_required_stops.html#further-reading.
/cc @niskhakova @eread