Announce the extension of the maintenance policy internally
Context
Once the pilot for the extension is over, and we're ready to rollout the extension of the maintenance policy for bug fixes, we need to align the announcement with the early branch creation process.
We're opting to announce both changes in the release processes together in order to help us reduce the noise and make the transition faster for gitlab team members.
This was discussed in delivery#21117.
Timeline
As discussed in #21117 (comment 2580116071) and Launch coordination: New monthly release proces... (#21430), we plan to internally announce both changes (maintenance policy extension and early branch creation) one month before the 18.4 release, on the week of August 18th (release week for 18.3). This is to give enough time for engineers to anticipate and prepare for these changes.
Announcement and feedback issue
https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/21474+
Slack Announcement
To increase engineering efficiency, GitLab engineers are now enabled to self-serve on backporting bug fixes into the maintained stable branches. No need for backport request issues to backport bug fixes for the maintained versions. This is an internal process change to foster adoption and measure the impact.
Communication channels
-
ChatOps announcement from #f_upcoming_release -
announcement in #engineering-fyislack channel -
forward announcement in #what's-happening-at-gitlabslack channel -
forward announcement in #productslack channel -
Add to Engineering Week-in-review
Exit Criteria
-
Draft announcement for internal GitLab team members -
Review and finalize communication content -
Determine appropriate communication channels -
Send announcement to internal team members -
Monitor and address any follow-up questions (continuing in https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/21474)