Skip to content

Release post - GitLab 15.6

🤖 GitLab Bot 🤖 requested to merge release-15-6 into master

Overview

Process Improvements? Have suggestions for improving the release post process as we go? Capture them in the Retrospective issue.

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

Release post:

Related MRs:

Related files:

Release post task and 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.

Reminding and Alerting DRIs:

It's important to keep PMs up to date regularly with items they need to deliver for the release post. Early reminders are especially helpful due to how async and distributed GitLab team members are. The release post manager will alert DRIs (PMs, EMs and others as needed) at least one working day before each due date (post a comment to the #release-post Slack channel, issues or MRs) per the release post manager task list below. But the release post manager can also opt to do addtional reminders or announements specific to the release post they're leading as they see fit.

Handbook references:

People:

Release post manager Tech writer Technical Advisor Social PMM lead Product Operations DRI Release post manager shadow
abellucci phillipwells brhea DRI: @wspillane & @social for Slack Checklist item anair5 @fseifoddini dorrino

Response time SLA:

To accommodate the tight timelines of tasks during the 18th-22nd of the month, members of the release post team are asked to commit to one-hour response times in Slack during their working hours on those dates.

Release post kickoff (abellucci) due by the 7th

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. If a task says "no earlier than", it is important to follow that guideline.

Opening tasks

Due date: 2022-11-07

  1. Confirm that the release-post-creation-task successfully completed the following:

    1. This MR has the active milestone assigned.
    2. This MR is labeled priority1 ~"blog post" release post release.
    3. All of the links in the Overview of this MR load the correct page.

  2. Read the RPM specific section of the release post handbook page in detail.

  3. 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.

  4. Consider setting up a coffee chat with the previous release post manager and/or Product Operations DRI to ask for tips and any helpful "latest info".

  5. After meeting with the previous release post manager and/or Product Operations for insights, consider setting up a meeting with your release post shadow (dorrino) to help them understand their role and how much capacity they have to support the work that month.

  6. 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 3rd of the next month in order to incorporate any process changes before the next release post automation 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.

  7. Create a 15-6-release-post-prep channel in Slack.

    1. Invite phillipwells, brhea, anair5, dorrino, @fseifoddini, and @brhea. There is no need to invite the social team to the channel.
    2. Post the following message in 15-6-release-post-prep: Hi team! This channel is to discuss production-specific topics that don't concern the broader product team. By keeping our conversations in this channel, we can help keep #release-post focused.

  8. Update the #15-6-release-post-prep Slack bookmarks in the #release-post channel:

MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/114276
Preview page: https://about.gitlab.com/releases/gitlab-com/
Review App: https://release-15-6.about.gitlab-review.app/releases/2022/11/22/gitlab-15-6-released/
Retro issue: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/14161
MVP nomination: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/14160

  1. In #15-6-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 Technical Advisors.
    • Tell them that if they have any questions, post them to you in the #15-6-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.

  2. Update the #release-post Slack bookmarks in the #release-post channel:

MR: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/114276
Preview page: https://about.gitlab.com/releases/gitlab-com/
Review App: https://release-15-6.about.gitlab-review.app/releases/2022/11/22/gitlab-15-6-released/
Retro issue: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/14161
MVP nomination: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/14160
  1. 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.
  2. Schedule at least two sync 15-minute weekly standups using this agenda as an example. Considering the timezones of the RP team and/or potential holidays over the weekend, consider not scheduling the sync stand-ups on Mondays.
  • The standups should ideally happen the 2nd and 3rd weeks of the month to allow for collaboration leading up to the 17th.
  • Add attendees TW Lead, Tech advisor as required and the PMM Lead and Product Operations DRI as optional.
  • If times zones conflict too much, initiate at least two weekly virtual standups to happen at the same time/day of the week in Slack #15-6-release-post-prep channel. Leverage the agenda template above to conduct it.
  • For any who can't attend, recordings should be posted in the agenda and/or Slack #15-6-release-post-prep channel after the standup.
  • Please note a sync standup is always required for major releases.
  1. Review the release post major due dates in the standup agenda you created. If any fall on a weekend, Family and Friends 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.
  2. 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.
  3. Remind the Technical Writer in Slack prep channel to not to merge in changes from master to the release post branch. See the Release post branch ownership section above for more details.

Release post item creation reminders (abellucci) due by the 10th

Initial reminders

Due date: 2022-11-10

  1. Paste the following message in #release-post 
@product-team 📣 Release post reminders 📣

1. Today is the day to have your release post items created and in review by your PMM and TW counterparts.
2. Please follow the [file naming guidelines](https://about.gitlab.com/handbook/marketing/blog/release-posts/#instructions) as it affects the release post template as well as the release post team's ability to find release post items with ease.
3. Please work with your EM to add high-impact bugs to the [release-x-y-bugs MR](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/114277)
4. Please work with your Product Designers to highlight significant usability improvements in the [release-x-y-usability-improvements MR](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/114278)

cc: @fseifoddini @brhea
  1. Paste the following message in #development and #eng-managers 
Your notable bugs and performance improvement MRs are ready to receive your contributions.

- https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/114277
- https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/114279

cc: @fseifoddini @brhea
  1. Paste the following message in #ux_leadership 
Your notable usability improvement MR is ready to receive your contributions!

- https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/114278

(Remember that we have to limit the content block to [notable improvements](https://about.gitlab.com/handbook/marketing/blog/release-posts/#contributing-to-usability-improvements) but you can add as many items as you'd like to the [UI Polish gallery](https://nicolasdular.gitlab.io/gitlab-polish-gallery/)`.)

cc: @fseifoddini @brhea

General contributions (abellucci) due by the 10th

The release post is authored following a changelog-style system. Each item should be in an individual YAML file. See the Handbook: Contributing to the release post.

Content blocks

Due date: 2022-11-10

Product Managers are responsible for raising MRs for their content blocks and ensuring they are reviewed by necessary contributors by the due date. Content blocks should also be added for any epics or notable community contributions that were delivered.

Product Managers are also responsible for making sure all Tech Writing reviews (required), and PM Director and PMM reviews (recommended) are done for their content blocks. To help reviewers prioritize what to review, PMs should communicate which content blocks are most important for review by applying the proper labels to the release post item MR prior to assigning the MR to reviewers. (ex: Tech Writing, Direction, Deliverable, etc). PMs can also follow these guidelines to help decide which content blocks should get PM Director and PMM reviews.

To enable Engineering Managers to merge the content blocks as soon as an issue has closed, PMs should ensure all scheduled items have MRs created for them and have the Ready label applied when content contribution and reviews are completed.

Reminder: be sure to reference your Direction items and Release features. All items which appear in our Upcoming Releases page should be included in the relevant release post. For more guidance about what to include in the release post, check the Product Handbook.

Recurring content blocks

Due date: 2022-11-10

The following sections are always present and managed by the PM or Eng lead owning the related area. As release post manager, you do not need to act on the checkboxes below. You will be asked to send a reminder ping later in the process.

Recurring items (abellucci) 12th onward

Maintain (rebase) the branch

  1. Occasionally 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.

Content assembly and initial review (abellucci) 12th - 15th

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.

Due date: 2022-11-12

  1. Encourage team members to vote on MVP nominations in the #release-post, #community-relations, #mr-coaching and #core Slack channels by sharing a link to the MVP Issue.
  2. 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, ux_leadership, and #eng-managers by the 12th. If you check the Also send to #channel box when commenting on a thread, it will also post your response in the main channel. This is a great way to signal-boost the reminders.

General Content Review due by the 14th

Due date: 2022-11-14

As PMs finalize their release post items it can be helpful for the RPM to review and offer feedback. This reduces pressure on the 17th as items are merged and provides additional review from someone with a fresh perspective.

  1. You can start as early as the 12th, but it should be an ongoing task leading up to content assembly on the 18th.
  2. Review each MR labeled Ready for content that follows handbook guidance. See What RPM should look for when reviewing content blocks.
  3. When you have finished reviewing a merge request, Approve it to clearly communicate who has reviewed and approved the content of the release post item.
  4. Add the rp manager reviewed label to release post item MRs you have reviewed and approved. This may seem redundant, but it will allow you to search for release post items that have been merged before you have reviewed them.
  5. It can also be helpful to filter MRs using the Approved-By != <yourself> to easily track what needs work.

To track release post items you haven't reviewed, bookmark filtered MR lists similar to the following:

  1. Release post item MRs with the ~Ready label
  2. Merged release post item MRs without the ~"rp manager reviewed" label
  3. Release post item MRs for this milestone
  4. Deprecation item MRs (in the gitlab project) for this milestone

Various tasks and followups due by the 15th

Due date: 2022-11-15

  1. In the #release-post channel remind all PMs that have their release post item MRs merged by EOD on the 17th or bump the milestone if they know it won't make it.
  2. No later than the 15th, if final contnet review dates fall on a weekend, Family and Friends day or other holiday, post a message in Slack #release-post letting the final reviewers @Sid and @david know you'll be requsting review from them over the weekend. Cc the TW lead and Product Operatoins DRI.
  3. Provide the list of the primary features to VP of Product @david in #release-post and recommend a top feature.
    • Tip: If you're using an IDE such as VS Code, search for primary: and add data/release_posts/15_6 to the files to include input.
  4. Select a cover image for the release post.
  5. Verify that the selected cover image has not been used before.
    • Tip: 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.
  6. On the release-15-6 branch, add the cover image to source/images/15_6/15_6-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.
  7. On the release-15-6 branch, in sites/uncategorized/source/releases/posts/2022-11-22-gitlab-15-6-released.html.md, add the cover image path for the image_title and twitter_image keys. Also, add details about the source image.
  8. Choose an MVP for this release based on what's surfaced in the MVP issue.
    • Tip: Contributors are only eligible to be MVP once per major release. A quick way to check past MVPs is to view /data/mvps.yaml.
    1. If no MVP nominations have been added to the MVP issue by the 15th, send reminders in Slack 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.
    2. After one or more quality nominations have been received, choose one and notify the #release-post channel of your choice. Use this chance to confirm that the contribution your MVP choice was nominated for will make it into this release.
  9. Before handing off the bugs, usability, and performance improvements MRs to the TW lead for final review, remind PMs/EMs about the content due date by revisiting and commenting on the Slack threads you created by the 10th in #release-post, #development, and #eng-managers. Let them know it's the "last call" and no further contributions to the MRs will be taken after the 15th.
  10. In the threads of this MR, look for a GitLab Mattermost update, similar to this example comment. Thank the poster, then tag the Distribution PM as an FYI and ask them to check the box and resolve the thread.
  11. Tag the Runner PM in a new comment as an FYI and ask them to check the box and resolve the thread.
  12. Remind PMs to review existing deprecations on the Docs page in case any edits are needed.
  13. Assign Bug Usability improvements and Performance Improvement MRs to the technical writer.
    • Note: Each of these MRs contains additional Todos and due dates. Be sure to check them carefully for actions due before the ones below on the 17th.

Final merge related tasks (abellucci) due by the 17th

Due date: 2022-11-17

Engineering managers listed in the MRs are responsible for merging content blocks (release post item MRs) 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.

Due date: 2022-11-17

  1. In the #x-y-release-post-prep channel, remind the team that from the 18th-22nd, release post team members are asked to maintain a one-hour response time in Slack during their working hours. This is to ensure the smooth progression of time-sensitive tasks during this window.
  2. 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.
  3. Mention the Distribution PM in the #release-post channel, reminding them to add any relevant upgrade warnings by doing an upgrade MR.
  4. Finalize your MVP selection and work with the person that nominated the MVP to write the MVP section in data/release_posts/15_6/mvp.yml on the release-15-6 branch.
    1. On the release-15-6 branch, add the MVP's name and other profile info to data/mvps.yml.
    • 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.
  5. Merge Bug Usability improvements and Performance Improvement MRs.
  6. Ping Product Operations @brhea to generate the deprecations and removals indexes.
  7. The release post manager will proceed with their tasks as this task will be completed by @brhea asyncrhonously prior to the publication date. However, if @brhea will be unavailable from the 18th through the 20th, collaborate with your technical advisor to complete the following steps yourself:
    1. Run bin/rake gitlab:docs:write_deprecations in the gitlab repo @brhea.
    2. Run bin/rake gitlab:docs:write_removals in the gitlab repo @brhea.
    3. Copy and paste the output files to the data directory in this repo @brhea.
  8. Paste the following message in #release-post 
@product-team 📣 Content assembly 📣

1. Content assembly will happen via automation on the 18th at 4 pm UTC (11 am ET / 8 am PT).
1. Any un-merged MRs after that time should no longer target `master`.
1. Follow the steps here if you need to merge your items after the automation has run: `https://about.gitlab.com/handbook/marketing/blog/release-posts/#adding-editing-or-removing-merged-content-blocks-after-the-18th-and-before-the-22nd`

cc: @fseifoddini @brhea

Content assembly (abellucci) due on the 18th

Due date: 2022-11-18 at 4 pm UTC (11 am ET / 8 am PT) and NO earlier

On the release-15-6 branch:

  1. Verify the presence of .yml files in the 15_6 data directory: data/release_posts/15_6/.
  2. Verify the absence .yml files in the unreleased data directory: data/release_posts/unreleased/.
  3. Verify the presence of image files in the 15_6 image directory: source/images/15_6/.
  4. Verify the absence of image files in the unreleased image directory: source/images/unreleased/.
  5. Do a check of the blog post and ordering of content blocks for secondary items to confirm they are grouped by stage in descending alphabetical order.
    • Tip: be sure to wait until after the content bot runs. Otherwise, content may be missing or incomplete.
    • If any of the steps above cannot be verified, content assembly may have failed. Mention @brhea and brhea in a comment on this MR and in #x-y-release-post-prep and proceed with the steps below. Optionally, you may choose to move the files manually by following the steps outlined here.
  6. Update the release post intro in the sites/uncategorized/source/releases/posts/2022-11-22-gitlab-15-6-released.html.md with 4 primary features to highlight. To do this:
    1. Make sure to remove the backticks around the features.
    2. Make sure to update the feature placeholder text for title: and description:.
    3. 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.
    4. 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 and remove the backticks in sites/uncategorized/source/releases/posts/2022-11-22-gitlab-15-6-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.
    5. Replace the XX in We thank our community for the XX contributions with the count of merged milestones found in this query. Remove the backticks as well.
    6. Change the entry for the top feature from primary to top based on the feedback from VP of Product @david.
      1. If you did not receive feedback, you may either choose the feature you recommended or solicit feedback from @product-team in #release-post.
  7. Update the yml block that will announce the release post after it is published.
    • The release post kickoff task has already created a branch and MR in the project that generates the homepage. But, you will need to update a few fields with information about this release post. You will be updating the contents of the card block that has event_type: "Release".
    1. Follow this link to edit the contents of index.yml in the 15-6-release-post-changes branch.
      1. (If the link doesn't take you directly to the section to edit, use your browser's find command to search for event_type: "Release" to quickly locate the yml block you will be updating.)
    2. Update header and data_ga_name with a copy/paste of the blog title. For example, GitLab X.X released with Feature A and Feature B.
    3. Update the href line with the URL of the blog. For example, /releases/2021/06/22/gitlab-14-0-released/.
    4. Update image (line 119) to the current version (note that we have pre-made all 15_*.png images, anything beyond that may need a design resource). Example: /nuxt-images/home/resources/15_1.png
    5. Commit your changes with a commit message of "Updates to release post homepage content".
    6. Add @mpreuss22 and an engineer on the Digital Experience team Conversion Group as a Reviewer (commonly, @justin.vetter or @tywilliams).
    7. Ping @mpreuss22 or @justin.vetter in #digital-experience-team on Slack to review the changes, with a link to your MR.
  8. Ensure that the social sharing text is available and correct on release post. This text comes from the title: element in sites/uncategorized/source/releases/posts/2022-11-22-gitlab-15-6-released.html.md and should appear below the post introduction inside the social sharing block. View the release post in the review app and look for Click to tweet! to find the social sharing text.

Hand off for TW review (abellucci) due on the 18th

TW review cannot proceed if content assembly is incomplete. Only perform these steps if the content assembly verification you performed above has passed.

Due date: 2022-11-18

  1. Label this MR: ~"blog post" release.
  2. Make sure there are no broken links in the review app (View App) page (use a dead link checker like Check my Links).
    1. 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).
    2. 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.
  3. Check all comments in the MR thread (make sure no contribution was left behind).
  4. Make sure all discussions in the thread are resolved.
  5. Confirm the list of deprecations and removals in the release post reflects the deprecations and removals in docs. On the docs pages, all H2 titles that apply to the release should be listed as bullets at the bottom of the release post. Ping @brhea and @fseifoddini in #x-y-release-post-prep if there is a mismatch.
  6. Check if any removals in this release post milestone are indicated as "Breaking Changes" in docs. Ping @brhea and @fseifoddini in #x-y-release-post-prep if so.
  7. 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.
  8. Assign the MR to the next reviewer (Technical Writer lead) and ping them to complete the structural check.
  9. Ask the Technical Advisor in Slack #15-6-release-post-prep channel to prep handoff of any release post issues to the next Technical Advisor by referencing TA handoff.

Final content review (abellucci)

In the run-up to publishing the release post on the 22nd, some release post managers have found it helpful to post a daily summary to the team in x-y-release-post-prep. This is not a requirement, but it can prove helpful to communicate status to the rest of the team and invite feedback if something is missed or off-track.

Due date: 2022-11-19

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

Verify content and post for review

  1. Check to be sure there are no broken links in the View app (use a dead link checker like Check my Links.
  2. Check the review app URL on social media 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.
    1. 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. Also try checking the title:, description: and twitter_image: values in the release post markdown file as these are used for generating then social media metadata.
    2. You may get a warning from Facebook that says Missing Properties - The following required properties are missing: fb:app_id - this can be ignored.
  3. 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.
  4. Mention @Sid, @david in the #release-post channel when the post has been generated for their review per these communication guidelines.
  5. 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.

Create the What's New MR

  1. Identify the 3-7 items for What's New and create the MR by following the guidance in Creating an MR for What's New entries.
  2. Post the following message in #backend_maintainers on Slack: I am the release post manager for XX.Y and will need help merging in the "What's new" notification following the publication of the release post. This will be a time-sensitive MR on the 22nd (15:00-19:00 UTC). Could I please request a volunteer or two to be ready and available to help merge the MR when I have it ready to go? Thanks! cc: @a_akgun
  3. Create and finalize the MR draft by 11:59 PDT on the 21st.
  4. Tag in What's New DRIs Product Operations @fseifoddini and @brhea and VP of Product @david as Reviewers, to review and Approve.
  5. Tag in any maintainers who respond to the above message in #backend_maintainers as Reviewers, to review and Approve.
  6. If you do not have merge rights on gitlab-org/gitlab, mention to the maintainers you've tagged above that you will need them to merge this MR after the release post is live on the 22nd. (There is a task on the 22nd reminding you to merge or request to merge.)

Prepare and merge to master (abellucci) 20th - 22nd

Due date: 2022-11-20

Incorporating Feedback

  1. Make sure all feedback from CEO and Product team reviews have been addressed by working with the DRIs of those areas as needed.
  2. If you receive feedback about the ordering of the primary Items, you might need to adjust the order.
  3. If needed. re-order secondary items by adjusting the titles in the content blocks. More information to consider about altering secondary items in the content review guidelines and feature order technical instructions.
  4. Make sure there are no open feedback items in this MR or in the #release-post channel.

ProdOps Review

  1. On the 20th, ping Product Operations DRI (@fseifoddini ) for final check in the #release-post channel. You should also assign them as a reviewer to the release post merge request.
  2. After the Product Operations review, the Product Operations DRI (@fseifoddini ) will approve the release post merge request.

Branch maintenance

  1. 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/15_6, and also count the number of items in the performance improvements and the usability improvements files in the current release-15-6 branch. Do not include bugs, upgrades, etc. You can use an approximate count (i.e. 40+ instead of 43). Remove the backticks around the number if you have not already.
  2. Check if the number of merged community contributions you added in the introductory paragraph has changed. Remove the backticks around the number if you have not already.
  3. 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. If no conflicts appear, consult with the Tech Advisor to resolve them locally.

Announcements

  1. Alert the product team of the top/primary items in Slack.
    1. PMs can use this query (update it with the current milestone) and check with their EMs to verify the features did make it into the release.
    2. 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._
  1. Top/Primary items can move.
    1. 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.
    2. 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:
      1. Technical Marketing (the TMM team), who produce demo videos per release.
      2. Social Marketing, who produce feature campaigns per release.
      3. Corporate Communications, who lead media outreach and may have produced a press release.
      4. Any other related efforts you're aware of, for example related blog posts.
  2. Post a comment in the #whats-happening-at-gitlab channel.
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/114276
Review app (this link is temporary and should only be shared internally):
https://release-15-6.about.gitlab-review.app/releases/2022/11/22/gitlab-15-6-released/index.html
cc abellucci @fseifoddini @brhea

Due date: 2022-11-21

  1. Mention @community-team in the #community-relations channel to ask them to send the swag pack to the MVP.
  2. Check if all the anchor links in the intro are working.
  3. Confirm there are no broken links in the review app (View app) with a dead link checker like Check my Links).
  4. 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/15_6 on the current release-15-6 branch.
  5. Use the /rebase quick action to rebase master on to the release-x-y branch. If you receive an error that the rebase cannot be scheduled, consult with @brhea or the Tech Advisor.
  6. 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-escalationchannel in Slack then cross-post to the #release-post channel to make others aware.
  7. In the #releases channel, post the following: " I'm the release post manager for X.Y. I'll be awaiting your cue that packages have been released to push the release post live. Please let me know if there are any changes to the typical timeline."

Due date: 2022-11-22

At 12:30 UTC
  1. Read the important notes below.
  2. 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.
    1. 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.
    2. If everything is okay, the packages should be published around 13:30 UTC, and available publicly around 14:10 UTC.
  3. Check to make sure there aren't any alerts on in the #release-post and #whats-happening-at-gitlab channels.
  4. Check to make sure there aren't any alerts on this MR or merge conflicts.
When packages are published (usually around 13:30 UTC)

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

  1. 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.
    1. 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.
  2. Add the MR to the merge train.
  3. Wait for the pipeline. This can take anywhere from 20-45 minutes to complete.
  4. 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.
    1. 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.
    2. You may get a warning from Facebook that says Missing Properties - The following required properties are missing: fb:app_id - this can be ignored.
  5. Check for broken links again after the post is live.
  6. 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).
  7. Share the links to the post on the #release-posts and #whats-happening-at-gitlab channels in Slack.
  8. Ping an engineer on the Digital Experience Conversion Group team to merge the homepage update MR (link to the MR should be found in here).
  9. Merge (or request a maintainer to merge) the "What's New" MR after the images referenced in that MR have been checked to load correctly locally.
After the MR is merged
  1. 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.

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
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

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

Due date: 18th (phillipwells)

The structural check is performed by the technical writing lead: phillipwells

When starting the structural check:

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:

  1. Clear typos, like this is a typpo
  2. Minor front matter issues, like single quotes instead of double quotes, or vice versa
  3. 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:

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

In the review app:

  1. Check that images match the context in which they are used, and are clear.
  2. Check for duplicate entries.
  3. Search for the text gitlab-ci.yml and ensure there is a period before the filename, for example, .gitlab-ci.yml.
  4. Check that features introduced in this release do not mistakenly reference previous releases (this often happens after features slip to a future release after an RPI is already written). If, for example, the current release is 13.8, and an item reads: "In GitLab 13.7 we introduced XXX...", this means the feature most likely slipped to 13.8. In that case, correct the text to "In GitLab 13.8 we introduced XXX...". A search for two or three previous release numbers ("13.7", "13.6", and "13.5" in our example) in the review app should be enough to spot this.
  5. Check all dates mentioned in entries, ensuring they refer to the correct year.
  6. Check the anchor links in the intro. All links in the release post markdown file should point to something in the release post YAML file.
  7. Check for structural consistency between release post items. Check for consistent use of white space, lists, and punctuation.
  8. Run a dead link checker like Check my Links and ping reporters directly on Slack asking them to fix broken links.
  9. 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).
  10. Run a spelling check against the release post's review app (View app) page. For example, you can use Webpage Spell-Check for Google Chrome.
  11. Confirm the list of deprecations and removals in the release post reflects the deprecations and removals in docs. On the docs pages, all H2 titles that apply to the release should be listed as bullets at the bottom of the release post. Ping @brhea and @fseifoddini in #x-y-release-post-prep if there is a mismatch.

In general:

  1. 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.
  2. Ping the release post manager in Slack #15-6-release-post-prep to let them know your review is over and they can start final content review.
  3. Approve the release post merge request to communicate you have completed your tasks.
  4. Within 1 week, update the release post templates and release post handbook with anything that comes up during the process.
  5. Set a reminder for yourself on the 17th of the following month to prepare for the versioned documentation release.

Release highlights

anair5 shares the release highlights to be distributed to the PR and Field Enablement teams on or before 22nd of the month. Detailed process here.

  1. Create Product marketing issue with PMM-Release-Post template.
  2. Create release highlights - 3-4 themes with description.
  3. Share with PR and Field enablement team and tag release post manager.
Edited by Hannah Sutor

Merge request reports