Slower rotation of Release managers (#39) · Issues · GitLab.org / release / tasks · GitLab (original) (raw)
Slower rotation of Release managers
At the moment we have release managers rotating monthly. We also have release trainees that shadow the release process before they come up as the new Release managers.
What we've seen in the past is that trainees do not pay that much attention to the release process until the final RCs, release and sometimes even up until they are supposed to start preparing fresh RC. You can be easily fooled with how much work there is if you just watch the process.
I propose that we have the current release managers as trainers of the new release managers. This would be a more hands on approach. This could look something like:
Month 1: RM1 and RM2 are running the process. RM3 and RM4 can observe the process, prepare their access. Month 2: RM3 and RM4 are running the process. RM1 and RM2 are responsible for keeping the RM3 and RM4 on track and helping them with the process. This would include daily check-ins, making sure that the overall process runs on time, helping new RMs with escalations and so on. By the middle of the release cycle, RM1 and RM2 should be doing less work. RM5 and RM6 are starting with onboarding. Month 3: RM5 and RM6 are running the process. RM3 and RM4 are coordinating release. RM1 and RM2 are out of the cycle
This means that release managers have a 2 month cycle, 1 month is hands on with tasks and second month is hands on with coordination with other release managers. The amount of work one RM would do is actually going to decrease because of the frequency.
I am curious if there are any drawbacks with this type of rotation.