Release post - GitLab 14.10 (!101764) · Merge requests · GitLab.com / www-gitlab-com

🤖 GitLab Bot 🤖 requested to merge release-14-10 into master Apr 02, 2022

Links and Reference

Expand

Previews

Preview page (shows the latest merged content blocks, for reference use until the 17th)
View App (shows the introduction, MVP and latest merged content blocks, for reference use between 18th - 21st

Release post

Related MRs

Related Issues

Related files

Handbook references

People

Release post manager	Tech writer	Technical Advisor	Social	PMM lead	Product Operations DRI
`@brhea`	`@marcel.amirault`	`@m_frankiewicz`	DRI: `@wspillane` & `@social` for Slack Checklist item	`@supadhyaya`	`@fseifoddini`

Release post branch ownership

The Release Post Manager is solely in charge of changes to the release post branch. To avoid potential merge conflicts later during content assembly, it is imperative that Technical Writers do not merge updates from master to the release post branch even if it is falling behind or if there is a conflict. The Release Post Manager will take care of conflicts as part of the content assembly process on the 18th and work with the Technical Advisor as needed.

Kickoff

Complete by the 7th (@brhea)

Expand

Note: Throughout the release post process, you'll do various Slack reminders/announcements. It is recommended you cc the Product Operations DRI and the rest of your release post team as you do these Slack posts because it helps keep everyone on the same page. Some Release Post Managers, pre-schedule messages in Slack for the respective notifications.

Note: There are several tasks in this checklist that can be done any time before the listed due date. These are indicated by a "🟢". If a task says "no earlier than", it is important to follow that guideline.

Opening tasks due by the 7th

🟢 Confirm that the release-post-creation-task successfully completed the following:
- This MR has the active milestone assigned
- This MR is labeled priority1 ~"blog post" release post release
- All of the links in the Overview of this MR load the correct page
🟢 Read the RPM specific section of the release post handbook page in detail
🟢 Review the rest of the release post handbook page and all the tasks in this MR template, not just your own, so you're familiar with the overall process, roles and tasks involved
🟢 Prior to your first team standup consider setting up a coffee chat with the previous release post manager and/or Product Operations to ask for tips and any helpful "latest info"
🟢 After meeting with the previous release post manager and/or Product Operations for insights, consider setting up a meeting with your release post shadow to help them understand their role and how much capacity they have to support the work that month
Schedule a 30 min Live Retrospective meeting for some time after the 22nd. All action items for the retro need to be completed prior to the 1st of the next month in order to incorporate any process changes before the next release begins. Make sure to invite Product Ops to the Live Retro meeting. Product Ops will need to approve any major updates to the process identified during the Retrospective.
🟢 Add the release number to sites/uncategorized/source/releases/posts/2022-04-22-gitlab-14-10-release.html.md and make sure to remove the backticks.
🟢 Add your name as the author to sites/uncategorized/source/releases/posts/2022-04-22-gitlab-14-10-release.html.md
🟢 Update the "which includes our YY release kickoff video" line replacing the YY (including removing the backticks) to reference the next release in sites/uncategorized/source/releases/posts/2022-04-22-gitlab-14-10-release.html.md
🟢 Per guidance on communication for the release, create the 14-10-release-post-prep channel in Slack and invite @marcel.amirault, @m_frankiewicz, @supadhyaya, the Product Operations DRI and the release post manager shadow (whoever is running the next release post). Let them know this channel is to discuss production-specific topics that don't concern the broader team, so we can keep #release-post focused and easy to follow. As a topic, add the release post MR, the link to the review app, and the link of the retro issue:

🟢 Update the #14-10-release-post-prep Slack channel topic and slack bookmarks in the #release-post channel:

MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/101764
Preview page: https://about.gitlab.com/releases/gitlab-com/
Review App: https://release-14-10.about.gitlab-review.app/releases/2022/04/22/gitlab-14-10-released/
Retro issue: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13230
MVP nomination: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13229

🟢 In #14-10-release-post-prep ask the TW Lead and Technical Advisor to familiarize themselves with their role by reading their section of the release post handbook page.
- Link to their handbook sections: TW Lead and TA
- Tell them that if they have any questions, post them to you in the #14-10-release-post-prep Slack channel and cc Product Operations
- Tell them it's recommended they set up a coffee chat with their predecessor for any helpful tips. The previous TW lead and TA can be found on the RP scheduling page
- 🟢 Update the #release-post Slack channel topic and slack bookmarks in the #release-post channel:
```
MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/101764
Preview page: https://about.gitlab.com/releases/gitlab-com/
Review App: https://release-14-10.about.gitlab-review.app/releases/2022/04/22/gitlab-14-10-released/
MVP nomination: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13229
```
🟢 Announce yourself as the Release Post Manager in the #release-post channel, as well as the Technical Advisor, and TW lead for reference. cc the Product Operations DRI
🟢 Ask your release post team in Slack prep channel if they prefer sync or async standups, and schedule them accordingly. Let them know the purpose of this standup is to discuss/troubleshoot if needed.
- If they prefer sync, set up two to three weekly, 15-minute standups to happen prior to the 17th with attendees TW Lead, Tech advisor as required and the PMM Lead and Product Operations DRI as optional.
- Use this agenda template
- If times zones conflict too much, or if your team prefers async, initiate two to three weekly virtual standups to happen same time/day of the week in the Slack prep channel prior to the 17th. It is recommended you leverage and link to the templated agenda doc to collect discussion items.
- Please note a sync standup is always required for major releases, for any who can't attend, recordings should be posted in the agenda and/or Slack prep channel after the standup
🟢 Review the release post major due dates in the standup agenda you created. If any fall on a weekend, Friends & Family day or other holiday, flag this to your release post team in Slack prep channel for awareness and to initiate any necessary planning to ensure smooth handoffs/completion of tasks over weekends, etc.
In the #release-post Slack channel, remind Product Managers that all content blocks (features, recurring, bugs, etc.) should be drafted and under review by the 10th. All direction items and notable community contributions should be included in the release post.
🟢 Confirm your local dev environment is running a current version of Ruby. See Handbook section Local dev environment setup to run content assembly script. Ask the Technical Advisor for help.
- If you have any difficulty installing dependencies, reach out to your Technical Advisor.
Remind the Technical Writer (either via slack or weekly standup) not to merge in changes from master to the release post branch. See the Release post branch ownership section above for more details.

Bugs, Usability, Performance reminders

Complete on the 9th (@brhea)

Expand

Add the following comment on this MR:

@gitlab-com/backend-managers and @gitlab-org/frontend/frontend-managers Your notable bugs and performance improvement MRs are ready to receive your contributions.

Bugs MR

Performance Improvements MR

🟢 Share the following message in the #development and #eng-managers Slack channels.

Your notable bugs and performance improvement MRs are ready to receive your contributions.

Bugs MR

Performance Improvements MR

🟢 Share the following message in the #ux_managers Slack channel.

Your notable usability improvement MR is ready to receive your contributions. Please work with your Product Manager to add entries. Remember that we have to limit the content block to notable improvements but you can add as many items as you'd like to the UI Polish gallery

Usability improvements

🟢 Share the following message in the #release-post Slack channel.

Your notable bugs, performance improvement, and usability improvement MRs are ready to receive your contributions. Please work with your EMs and UX designers to add entries.

Usability improvements

Bugs MR

Performance Improvements MR

🟢 Share the following message in the #release-post Slack channel.

@product-team Reminder to open your release post item content blocks (due tomorrow the 10th!) please ensure the file names (in the unreleased folder) are prefixed with your stagename, dep, removal, or upgrade as mentioned here: https://about.gitlab.com/handbook/marketing/blog/release-posts/#instructions.

The sooner you start reviews with your EMs and PMMs the easier to make the 17th due date.

Ping Runner, Omnibus, Mattermost PM Leads and Announce MRs are Due

Complete on the 10th (@brhea)
Add GitLab Runner improvements: @DarrenEastman
Add Omnibus improvements: @dorrino
Add Mattermost update to the Omnibus improvements section: @dorrino
Share the following message in the #release-post Slack channel.

@product-team Today’s the day, PMs should have your release post items drafted and assigned to your EM, TW, PMM for review.

All content blocks should be marked as ~ready and merged by the 17th!

Please ensure the file names (in the unreleased folder) are prefixed with your stagename, dep, removal, or upgrade as mentioned here.

Rebase, Pipeline, MVPs, Reminders

Complete on the 12th (@brhea)

Expand

Maintain (rebase) the branch

Rebase this MR by typing in the command /rebase in a new comment in this MR. This will help keep your branch up to date with master. Consult with the Tech Advisor as needed.
Remove the Draft: pre-fix from the subject of this MR and run the pipeline by clicking Run Pipeline in this MR's Pipelines tab. When the pipeline is complete, add the Draft: pre-fix back to the MR title to prevent accidental merge. Consult with the Tech Advisor as needed.

Request MVP Nominations

🟢 Solicit MVP nominations in the #release-post Slack channel by sharing a link to the MVP Issue for collaboration.
Cross-link the message from #release-post to #community-relations, #mr-coaching and #core channels to maximize contributions.

Bugs, Usability, Performance Reminders

Remind PMs/EMs to contribute to the bugs, usability, and performance improvement MRs by commenting on the various Slack threads you initiated in #release-post, #development and #eng-managers on the 9th

Check on MVP Nominations

Complete on the 14th (@brhea)

If no MVP nominations have been added to the MVP issue, send reminders in Slack (#release-post #community-relations #mr-coaching #core) with the link to the MVP issue. An easy way to do this is to respond to your original Slack solicitation posts and resend to the whole channel.

Reassign Bugs, Usability, and Performance MRs

Complete on the 15th (@brhea)

Expand

Assign the Bugs, Usability and Performance MRs to @tw_lead for review and add the in review label to each MR.
If there are no usability improvements yet added, alert UX DRI @vkarnes in the Usability Improvements MR and ask for direction.
If there are no bug fixes or performance improvements alert Product Operations DRI @fseifoddini. Additionally, modify the content of the MR, referencing bugs or performance improvements as appropriate. For example, if you have no performance improvement highlights, you will update the copy from

In GitLab 14.10, we're shipping performance improvements for issues, projects, milestones, and much more!

to:

In GitLab 14.10, we're shipping performance improvements for issues, projects, milestones, and much more! You can see the full list here.

Select Images, select MVP, check Deprecations and Removals

Complete on the 15th (@brhea)

Expand

Select a cover image and update references

🟢 Select a cover image for the release post
🟢 Verify that the selected cover image has not been used before.

MacOS users: navigate to the source/images/ directory and use the search bar in the Finder to search for cover. Make sure the scope is set to only search images. This won't reveal all previous images, but the last couple of years have had pretty consistent naming.

🟢 On the release-14-10 branch, add the cover image to source/images/14_10/14_10-cover-image.jpg. Tip: Be sure to use an underscore (_) between release numbers, not a hyphen or dash (-).

Note that as you add references to the cover image throughout the release post branch, (including for social sharing) you need to match the filename and extension exactly. For example, if your image in the directory is cover_image.jpg but in another file, you reference it as cover_image.jpeg, it will not display as the extension does not match, so the file will not be found.

🟢 On the release-14-10 branch, in sites/uncategorized/source/releases/posts/2022-04-22-gitlab-14-10-released.html.md, add details about the source image.

Choose an MVP

Choose an based on nominations in the MVP issue
Notify the #release-post channel of your choice. Confirm that the MVP's contribution will make it into this release.
Work with the person that nominated the MVP to write the MVP section in data/release_posts/14_10/mvp.yml on the release-14-10 branch.
On the release-14-10 branch, add the MVP's name and other profile info to data/mvps.yml.

Deprecations and Removals

If there are no deprecation announcements for this milestone, do a search to see if there are any open or merged MRs for the current milestone.
- Depending on any discrepancies you find, engage the PMs in Slack #release-post
- If there are no deprecations MRs in the search, remind PMs to create deprecations MRs, if they have them for this milestone
Remind PMs to review existing deprecations on the Docs page in case any edits are needed.

Confirm Review of Bugs, Usability, and Performance MRs

Complete on the 16th (@brhea)

Expand

Confirm that Bugs MR has ready label and is assigned to @brhea
Confirm that Usability MR has ready label and is assigned to @brhea
Confirm that Performance MR has ready label and is assigned to @brhea

Merge Bugs, Usability, and Performance MRs

Complete on the 16th (@brhea)

Expand

Merge Bugs MR
Merge Usability MR
Merge Performance MR

Content assembly and initial review

Complete on the 17th (@brhea)

Expand

Engineering managers listed in the MRs are responsible for merging as soon as the implementing issue(s) are officially part of the release. All release post items must be merged on or before the 17th of the month. Earlier merges are preferred whenever possible. If a feature is not ready and won't be included in the release, the EM should push the release post item to the next milestone.

To assist managers in determining whether a release contains a feature. The following procedure documented here is encouraged to be followed. In the coming releases, Product Management and Development will prioritize automating this process both so it's less error-prone and to make the notes more accurate to release cut.

Mention the Distribution PM in the #release-post channel, reminding them to add any relevant upgrade warnings by doing an upgrade MR.
In the #release-post channel remind all PMs that it's the 17th, so they need to either have their EMs merge their release post item MRs or bump the milestone if they know it won't make it.
Use /rebase on the release post MR. If you receive an error that the rebase cannot be scheduled, resolve any conflicts appear in the merge request widget. If no conflicts appear, consult with the Tech Advisor to resolve them locally.
Perform a dry-run of the content assembly without pushing to master by completing the following commands:

  git checkout master
  git pull
  git checkout release-x-y
  git pull
  git merge master
  bin/release-post-assemble

You should get a list of changed files. If no errors have been detected, use git reset --hard to return back to your last commit.
If you get any errors, reach out to the Technical advisor for support and keep product operations and your TW lead informed as needed

Final content assembly

Complete on the 18th at 8 AM PT and NO earlier (@brhea)

Expand

Note: All the Final Content Assembly and Structural Check steps happen in sequence on the 18th starting ~8am PST (America/Los_Angeles). If the Release Post Manager and Technical Writer are in significantly different timezones, coordinate ahead of the 18th to understand how this could impact working hours for each team member. If need be, the time of initiating the final content assembly and the subsequent coordinated tasks can be shifted, as long as Final content review with the CEO and CProdO begins no later ~12pm PST on the 19th, to allow enough time for feedback and updates.

Ping Product Operations @brhea to generate the deprecations and removals indexes and check of the task list items below when done
- If @brhea is unavailable, collaborate with your technical advisor to complete the task yourself
- Run bin/rake gitlab:docs:write_deprecations in the gitlab repo @brhea
- Run bin/rake gitlab:docs:write_removals in the gitlab repo @brhea
- Copy and paste the output files to the data directory in this repo @brhea
Post in Slack #release-post notifying the team content assembly has begun and any un-merged MRs should no longer be merged to master. Point them to this link for info on how to merge MRs after content assembly has begun https://about.gitlab.com/handbook/marketing/blog/release-posts/#adding-editing-or-removing-merged-content-blocks-after-the-18th-and-before-the-22nd
Perform final content assembly by pulling all content block MRs merged to master into the release post branch by using the following commands locally (one command at a time):
```
git checkout master
git pull
git checkout release-x-y
git pull
git merge master
bin/release-post-assemble
git push origin release-x-y
```
Do a visual check of the release-14-10 content block and image folders to make sure paths and names are correct
Make sure the View App button shows up in the MR as expected
Do a visual check of the blog post and ordering of content blocks for secondary items to confirm they are grouped by stage in descending alphabetical order.
Update the release post intro in the sites/uncategorized/source/releases/posts/2022-04-22-gitlab-14-10-released.html.md with 4 primary features to highlight. To do this:
- Make sure to remove the backticks around the features
- Link the release post items mentioned in the intro to the item blocks within the release post. For example, for a feature named "Define test cases in GitLab", the link from the introduction should point to #define-test-cases-in-gitlab.
- Count the feature blocks to get the total number of improvements and add it to the intro, replace the XX in from the XX improvements including replacing (removing) the backticks in the sites/uncategorized/source/releases/posts/2022-04-22-gitlab-14-10-released.html.md. This count includes the top feature, primary features, secondary features, usability improvements, and performance improvements. Do not count bugs, upgrades, etc. You should use an approximate count (i.e. 40+ instead of 43) because the number can shift after the release post goes live.
- Mark the first primary item, based on what the VP of Product Management decided, to appear on the page as top while the rest can remain primary or secondary.
🟢 Create a new "draft" merge request with the changes below and add @mpreuss22 and an engineer on the Digital Experience team as a Reviewer (commonly, @lduggan or @tywilliams). This MR goes directly live on the homepage when merged so it shouldn't be merged until the release post page is live. Make a note in the description that it shouldn't be merged until the release date.
- Update the release blurb for the homepage in the file: https://gitlab.com/gitlab-com/marketing/digital-experience/buyer-experience/-/blob/main/content/index.yml changing the following lines:
- 🟢 Update version (line 3) to the latest version.
- 🟢 Update subtitle (line 5) with a copy/paste of the blog title. For example, GitLab X.X released with Feature A and Feature B.
- 🟢 Update the button_url (line 7) line with the URL of the blog. For example, /releases/2021/06/22/gitlab-14-0-released/.
- Ping @mpreuss22 in #digital-experience-team on Slack to review the changes, with a link to your MR.
Ensure that the social media sharing text for the click to tweet button on the bottom of the release post is available in the introduction.
Notify the PM team in the #release-post channel that final content assembly has happened and all work must now shift from master to the release post branch via coordination with the release post manager.
- Include a link to how to merge MRs after the 18th https://about.gitlab.com/handbook/marketing/blog/release-posts/#adding-editing-or-removing-merged-content-blocks-after-the-18th-and-before-the-22nd
- Include a link to the review app (View App) page, asking them to make sure all their content is showing up as expected with correct image/video links, etc.

Note: If the release post assembly script fails, look at the bottom of this section of the release post handbook page for further instruction

Begin Review

Complete on the 18th after final content assembly (@brhea)

Expand

Label this MR: ~"blog post" release review-in-progress
Make sure there are no broken links in the review app (View App) page (use a dead link checker like Check my Links)
- Links to confidential issues may be missed. It is helpful to check for broken links as an unauthenticated GitLab user (either logged out, in another browser, or in Incognito mode).
- If there are links to external blogs that are still broken in the review app, check with PMs and others as needed to make sure the referenced blogs go live before the 22nd.
Check all comments in the MR thread (make sure no contribution was left behind).
Make sure all discussions in the thread are resolved.
If the pipeline is failing, confirm all release post content blocks have the right formatting. Common issues include extra spaces, missing quotes, or missing --- at the beginning and end. If you are unable to locate these items, give the TW lead a heads up and proceed with TW Lead structural check.
Assign the MR to the next reviewer (Technical Writer lead).
Ask the Technical Advisor in Slack #14-10-release-post-prep channel to prep handoff of any release post issues to the next Technical Advisor by referencing TA handoff

Final content review

Complete on the 19th (@brhea)

Expand

Note: The final review should happen after the TW Lead structural check is complete.

Check to be sure there are no broken links in the View app (use a dead link checker like Check my Links.
Check deprecations in Docs to see if there were any deprecations listed with a planned removal date for the current milestone. If so, make sure that you see those deprecations listed in the removals section of your release post page (View App). If there's any missing, alert the PM DRI to get it resolved.
Mention @Sid, @david in the #release-post channel when the post has been generated for their review per these communication guidelines.
Capture any feedback from Slack into a single comment on the Release Post MR with action items assigned to the DRIs to address. Check the content review guidelines for more details.

Last Check and Ping PMs

Complete on the 20th (@brhea)

Expand

Check if the number of features you added in the introductory paragraph has changed.
To get the number, do a hand count of just the features (top, primary, secondary) in /data/release_posts/14_10, and also count the number of items in the performance improvements and the usability improvements files in the current release-14-10 branch. Do not include bugs or upgrades. You can use an approximate count (i.e. 40+ instead of 43).
Remove the backticks around the number in the intro file if you have not already.
Use /rebase on the release post MR. If you receive an error that the rebase cannot be scheduled, resolve any conflicts that appear in the merge request widget. Consult with the Tech Advisor if necessary.
Post in the #release-post channel:
```
_Hello PMs! The following features are top/primary!_

(Provide link to review app (**View App**) and tag the PMs for the top/primary features listed in the release post).

_Please let us know if any of your merged primary release post items shifted out of the release after the 18th and will not make it into the final release packages by the 22nd._
```
- Tell them they can check this query (updated with the correct milestone) and check with their EMs to verify the features did make it into the release.
- It is the Release Post Manager's responsibility to make sure any top/primary items mentioned in the introduction are accurate prior to the 22nd, because release post items can sometimes move in/out of the packaged release after the 18th, and this could affect the themes, headline, etc.
If you learn that any top/primary items have moved in/out of the packaged release after the 18th, communicate this directly to stop or start associated actions, with the DRIs for:
- Technical Marketing (the TMM team), who produce demo videos per release.
- Social Marketing, who produce feature campaigns per release.
- Corporate Communications, who lead media outreach and may have produced a press release
- Any other related efforts you're aware of, for example related blog posts.

Incorporating Feedback

Complete on the 20th (@brhea)

Expand

Preparing to merge to `master`

Complete on the 21st (@brhea)

Expand

Mention @community-team in the #swag channel to ask them to send the swag pack to the MVP.
Check if all the anchor links in the intro are working.
Confirm there are no broken links in the review app (View app) with a dead link checker like Check my Links).
Check the total feature count statement in the introductory paragraph to make sure the number stated is accurate, and if not, update it. To get the number, do a hand count of the top feature, primary features, secondary features, and performance improvements (do not count bugs, upgrades, etc.) in /data/release_posts/14_10 on the current release-14-10 branch.
Work with your Technical Advisor to merge master into your release post branch before the 22nd. This reduces the risk of needing to resolve conflicts when merging the release post branch into master on the 22nd. This issue shows an example of how this process can be handled: #10886 (closed). After discussing with your Technical Advisor you might wish to remove the Draft: prefix from the MR, or merge master into your branch multiple times before the 22nd.
Check to make sure all unresolved threads on this MR are resolved and there are no merge conflicts. If you need help resolving merge conflicts or other technical problems, ask for help from the Technical Advisor in the #dev-escalation channel in Slack then cross-post to the #release-post channel to make others aware.
In the #releases channel, post the following: " I'm the release post manager for X.Y. I'll be awaiting your queue that packages have been released to push the release post live. Please let me know if there are any changes to the typical timeline."

Standby for Merge

Complete on the 22nd (@brhea)

Expand

At 12:30 UTC

Read the important notes below
Say hello in the #releases channel to let the release managers know you're online and awaiting their signal in #release-post to start the release post's merge process.
- Release Managers will alert you in #release-post if there are any issues with the release. You can follow along on the release issue to see the packaging progress on the 22nd. Check the issue list to find the issue (example issue). The #releases channel is also a good place to track any updates or announcements.
- If everything is okay, the packages should be published at 13:30 UTC, and available publicly around 14:10 UTC.
Check to make sure there aren't any alerts on in the #release-post and #whats-happening-at-gitlab channels.
Check to make sure there aren't any alerts on this MR or merge conflicts.

Merging to `master`

Complete on the 22nd (@brhea)

Expand

At 13:50 UTC

After the release manager confirmed that the packages are publicly available by pinging you in Slack:

Announce to the team in the #release-post channel that you are starting the final merge process, you will reach out for help if the MR fails, and that you will lead collaboration with the appropriate team members to resolve any problems.
- Depending on the complexity of the failure it is recommended that you first try to resolve the issue yourself and then reach out to the #dev-escalation channel per What to do if your pipeline fails or you have other technical problems.
Add the MR to the merge train at 14:10-14:20 UTC.
Wait for the pipeline. This can take anywhere from 20-45 minutes to complete.
Check the live URL on social media (after the MR is merged) with Meta Tags. Make sure that in both cases, you can see the cover image of the release post displayed along with social sharing copy
- If the cover image is not displaying or you see other error messages, resolve these issues by consulting with the Tech Advisor, Product Operations, or Social team as needed.
- You may get a warning from Facebook that says Missing Properties - The following required properties are missing: fb:app_id - this can be ignored.
Check for broken links again after the post is live.
Hand off social posts to the social team and confirm that it's ready to publish: Mention @social in the #release-post Slack channel. Be sure to include the live URL link and social media copy (you can copy/paste the final copy from the review app).
- A member of the social team will schedule the posts at the next available best time on the same day. The social team will mark the Slack message with a ⏳ once scheduled and add scheduled times to the post thread for team awareness. Further details are listed below in the Important Notes Section.
Share the links to the post on the #release-posts and #whats-happening-at-gitlab channels in Slack.
Merge gitlab-com/marketing/digital-experience/buyer-experience!425 (comment 918897599)
Merge the What's New MR after the release post is live on the 22nd and images have been checked to load correctly locally.

What to do if your pipeline fails or you have other technical problems

For assistance related to failed pipelines or eleventh-hour issues merging the release post, reach out to release post technical advisors for assistance in the #dev-escalation Slack channel. Cross-post the thread from #dev-escalation in #release-post so all Product Managers and release post stakeholders are aware of status and delays.

Important notes

The post is to be live on the 22nd at 15:00 UTC. It should be merged as soon as GitLab.com is up and running on the new release version (or the latest RC that has the same features as the release), and after all packages are publicly available. Not before. Ideally, merge it around 14:20 UTC as the pipeline takes about 40 min to run.
The usual release time is 15:00 UTC but it varies according to the deployment. If something comes up and delays the release, the release post will be delayed with the release.
Coordinate the timing with the release managers. Ask them to keep you in the loop. Ideally, the packages should be published around 13:30-13:40, so they will be publicly available around 14:10 and you'll be able to merge the post at 14:20ish.
After the release post is live, wait a few minutes to see if anyone spots an error (usually posted in the #whats-happening-at-gitlab or #company-fyi channels), then follow the handoff to social team checklist item above.
The tweet to share on Slack will not be live, it will be scheduled during a peak awareness time on the 22nd. After the tweet is live, the social team will share the tweet link in the #release-post and #whats-happening-at-gitlab Slack channels.
Keep an eye on Slack and in the blog post comments for a few hours to make sure no one found anything that needs fixing.

Other reviews

Ideally, the team should complete all the reviews by the 19th of the month, so that the 2 days before the release can be left for fixes and small improvements.

Structural check (`@marcel.amirault`)

Due date: 2022-04-18 (18th)

The structural check is performed by the technical writing lead: @marcel.amirault

Before starting the structural check:

Ensure that the docs release process is started (but not completed). This process should start around the same time as the release post structural check, and be completed soon after the release post goes live.

When starting the structural check:

Add the label review-structure.

For suggestions that you are confident don't need to be reviewed, change them locally and push a commit directly to save the PMs from unneeded reviews. For example:

Clear typos, like this is a typpo
Minor front matter issues, like single quotes instead of double quotes, or vice versa
Extra whitespace

For any changes to the content itself, make suggestions directly on the release post diff, and be sure to ping the reporter for that block in the suggestion comment, so that they can find it easily.

In the www-gitlab-com repository:

Check frontmatter entries and syntax.
Check that the item's name contains backticks when referring to code. (Previously we had to use single quotes, but backticks work now.)
Check all images (png, jpg, and gifs) are smaller than 150 KB each.
Remove any .gitkeep files accidentally included.
Add or check cover_img: license block in sites/uncategorized/source/releases/posts/2022-04-22-gitlab-14-10-released.html.md. Should include image_url:, license:, license_url:.
Search for available_in: [free, premium, ultimate] and change to available_in: [core, premium, ultimate].

In the review app:

In general:

Report any problems from the structural check in the #release-post channel by pinging the reporters directly for each problem. Do NOT ping @all or @channel, and do NOT leave a general message that no one will pay attention to. If possible, ensure open discussion threads in this merge request track any issues.
Notify the release post manager that you're done with the structural check needed for final content review, by pinging them in the #14-10-release-post-prep channel.

When the executive reviews are complete (on or after the 20th), post a comment in the #whats-happening-at-gitlab channel.

Mention the release post manager and product operations DRI. Template to use (replace links and mentions):

Hey all!
This month's release post is almost ready!
Take a look at the preview and either report any problems in #release-post, or leave a comment to the release post MR.
MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/101764
Review app (this link is temporary and should only be shared internally):
https://release-14-10.about.gitlab-review.app/releases/2022/04/22/gitlab-14-10-released/index.html
cc @brhea @fseifoddini

Remove the label review-structure.
Ping the release post manager in Slack #XX-release-post-prep to let them know your review is over and they can start final content review
Within 1 week, update the release post templates and release post handbook with anything that comes up during the process.

Edited Apr 22, 2022 by Brian Rhea

Release post - GitLab 14.10

Links and Reference

Kickoff

Opening tasks due by the 7th

Bugs, Usability, Performance reminders

Ping Runner, Omnibus, Mattermost PM Leads and Announce MRs are Due

Rebase, Pipeline, MVPs, Reminders

Maintain (rebase) the branch

Request MVP Nominations

Bugs, Usability, Performance Reminders

Check on MVP Nominations

Reassign Bugs, Usability, and Performance MRs

Select Images, select MVP, check Deprecations and Removals

Select a cover image and update references

Choose an MVP

Deprecations and Removals

Confirm Review of Bugs, Usability, and Performance MRs

Merge Bugs, Usability, and Performance MRs

Content assembly and initial review

Final content assembly

Begin Review

Final content review

Last Check and Ping PMs

Incorporating Feedback

Preparing to merge to master

Standby for Merge

At 12:30 UTC

Merging to master

At 13:50 UTC

What to do if your pipeline fails or you have other technical problems

Important notes

Other reviews

Structural check (@marcel.amirault)

Merge request reports

Preparing to merge to `master`

Merging to `master`

Structural check (`@marcel.amirault`)