- RP shadow 18.4 https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/140873 - Tech alternate 18.6 https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/141449 - Charts: https://lucid.app/lucidchart/75ee4c2b-6437-4f39-9f8e-01388d8dc13f/edit?viewport_loc=-1373%2C977%2C3860%2C1831%2C0_0&invitationId=inv_903fa9c5-57a5-4f4f-878e-86e7bb755550 ## Things to consider <details> <summary>considerations</summary> - Technical Issues: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues?sort=created_date&state=opened&label_name%5B%5D=Release%20Post%253A%253ATech%20Advisor - Process Issues (partially blocked by related issue) - Ownership Issues: PMM? Product? - Holistic view: What can we do to do better? - Who cares? Can we do release notes? Who gets value out of this? - Traffic: [GA report](https://docs.google.com/spreadsheets/d/1eJgTT7UOlYuLbDOYllyVIBVMH8rgvzRg3QH5-EUzYCQ/edit?gid=1901407927#gid=1901407927), is it driving to purchase? - What do different divisions think of it? Main lens to look through: What is the ROI? Time spent: - RPM: 8-12 hours - TW: 3-5 hours - Technical advisor: 3-5 hours - PMM: ? </details> ## Notes <details> <summary>notes</summary> Documentation: https://handbook.gitlab.com/handbook/marketing/blog/release-posts/ - 18.3 blog post: https://about.gitlab.com/blog/gitlab-18-3-expanding-ai-orchestration-in-software-engineering/ - 18.3 RP: https://about.gitlab.com/releases/2025/08/21/gitlab-18-3-released/ - 18.4 https://about.gitlab.com/blog/gitlab-18-4-ai-native-development-with-automation-and-insight/ and https://about.gitlab.com/releases/2025/09/18/gitlab-18-4-released/ - 18.5 https://about.gitlab.com/blog/gitlab-18-5-intelligence-that-moves-software-development-forward/ and https://about.gitlab.com/releases/2025/10/16/gitlab-18-5-released/ - 18.6 https://about.gitlab.com/blog/gitlab-18-6-from-configuration-to-control/ and https://about.gitlab.com/releases/2025/11/20/gitlab-18-6-released/ Dependencies of release post items: - What's new items in-app - release description in `https://gitlab.com/gitlab-org/gitlab/-/releases` - updated by the `update_project_releases_page  rake task defined on the www-gitlab-com repo https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/f728cb0dc7f6472a3b079052818b887c97fc0342/lib/tasks/update_gitlab_project_releases_page.rake - rake task is triggered by a CI job https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/f728cb0dc7f6472a3b079052818b887c97fc0342/.gitlab-ci.yml#L300 - `https://about.gitlab.com/releases/gitlab-com/` lists all items prior to official release Questions: 1. Release Post Manager filled by PMs: how do we ensure this is filled? - There's a [spreadsheet tracker](https://docs.google.com/spreadsheets/d/12tFW2nOqZ7Cxm0T-WKZVHmPdZNPtkS6fdIvLwvWVLLc/edit?gid=0#gid=0), but manually updated, by whom? how do new PMs get added? 2. Technical Advisor: volunteer role, how do we ensure this is filled? 3. How is PLT role determined? Rotation 4. Release Post standup doc still has references to Product Ops, how is this doc generated? 5. If technical work, such as improving the linter, needs to be done, who does that? TA when available </details> ## Patch release posts <details> <summary>Notes</summary> From `@mayra-cabrera` : We have some documentation https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/blog-post.md?ref_type=heads. Might be outdated Patch release characteristics: 1. Per the GitLab maintenance policy, patch releases include bug and security fixes to the [GitLab maintained versions](https://docs.gitlab.com/policy/maintenance/#maintained-versions) 1. Patches are released twice on Wednesdays around monthly release date - [Patch releases](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases/) - [Monthly releases](https://handbook.gitlab.com/handbook/engineering/releases/monthly-releases/) The process to create a patch blog post completely differs from the monthly blog post. Blog posts for patch releases are automatically created during the patch release process. Building a patch takes 3 business days: - Day 1 (Monday): Deployment of fixes - Day 2 (Tuesday): Patch is tagged - Blog post is automatically created here in a Security repository - Day 3 (Wednesday): Patch is released - Blog post is transferred to a Canonical repository after the patch is released Details: 1. One day before the patch due date. Release managers trigger a [CI pipeline](https://gitlab.com/gitlab-org/release-tools/-/blob/fd65f82b4b19a10eeab440af51a906d7882d407c/.gitlab/ci/security/release-preparation-ci.yml#L22) to automatically create the blog post 1. Release tooling fetches bug and security fixes from multiple GitLab repositories: 1. Bug fixes merged on canonical repos for all the maintained stable branches 1. Security fixes merged on security repos for all the maintained stable branches 1. Release tooling [assembles the blog post](https://gitlab.com/gitlab-org/release-tools/-/tree/master/lib/release_tools/patch_release/blog_post) in markdown format. 1. The blog post is created on the [www-gitlab-com security repository](https://gitlab.com/gitlab-org/security/www-gitlab-com/) - ([example](https://gitlab.com/gitlab-org/security/www-gitlab-com/-/merge_requests/254)) 1. **This is important, vulnerabilities should not be disclosed before the patch is available** 1. AppSec reviews, adjusts and approves the blog post 1. On the due date of the patch, after the packages have been published, release managers [trigger a CI pipeline](https://gitlab.com/gitlab-org/release-tools/-/blob/fd65f82b4b19a10eeab440af51a906d7882d407c/.gitlab/ci/security/publish-ci.yml#L55) to move the blog post to the ww-gitlab-com repository - ([example](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/142959)) 1. A pipeline on the www-gitlab-com repository is triggered and the blog post is available on the releases blog post page https://about.gitlab.com/releases/categories/releases/ Code can be found on release-tools. Particularly - CI job that triggers the creation of blog post on security https://gitlab.com/gitlab-org/release-tools/-/blob/master/.gitlab/ci/security/release-preparation-ci.yml?ref_type=heads#L22 - Code that generates the blog post https://gitlab.com/gitlab-org/release-tools/-/tree/master/lib/release_tools/patch_release/blog_post?ref_type=heads - CI job that moves the blog post to canonical https://gitlab.com/gitlab-org/release-tools/-/blob/master/.gitlab/ci/security/publish-ci.yml?ref_type=heads#L55 </details> ## Current state: chain of custody The release post currently serves multiple functions: 1. the release post itself, 2. "What's New" in-app items, and 3. release notes. However, these are not managed with a clear chain of custody. Using the [Pragmatic Institute Framework](https://www.pragmaticinstitute.com/product/framework/) as a lens, we should ask: do the right people own the right artifacts at each stage? ## Anatomy of the release post The release post is a composite of several distinct parts, each with a different natural owner: | Component | Description | Nature | |---|---|---| | Individual feature items | What shipped | Raw inputs | | Narrative framing | Top section with highlights, hero features, and thematic messaging | Where GTM value lives | | Structural assembly | Merge request handling | Operational/program management work | | Downstream outputs | "What's New" in-app, release notes on `gitlab-org/gitlab/-/releases` | Generated from the above | ## Current flow The current process conflates these under a single volunteer PM role. ```mermaid flowchart TD A["PM/EM authors feature items"] --> B["RP Manager (PM volunteer)<br/>handles narrative framing<br/>AND structural assembly"] B --> C["Release post published"] C --> D["PMM sees final output,<br/>crafts additional marketing material"] C --> E["What's New in-app"] C --> F["Release notes"] ``` {width=900 height=534} PMM is downstream — they receive the finished release post content and must absorb it to craft the marketing blog post. They are reacting to output rather than shaping the narrative. This limits go-to-market (GTM) effectiveness because messaging decisions are being made late in the process, by people whose primary role is not GTM. ### Key issues 1. **Ownership gaps** — Volunteer roles (RPM, Technical Advisor) difficult to fill consistently 2. **Role conflation** — Narrative framing and structural assembly handled by one role, rather than matched to the right people 3. **Late GTM visibility** — PMM only sees the final output, limiting narrative alignment across release assets 4. **Independent activity** — No consideration for how the release post fits into the broader user and buyer experience 5. **Technical debt** — Improvements to tooling lack clear ownership 6. **Unclear ROI** — High effort, but value/conversion unclear ## Possible Options | Option | Description | Benefits | Downsides | |---|---|---|---| | **Option 1: Rotation added** | Continue current process, but with defined rotations for roles | • Minimal process changes | • Only addresses ownership gaps, other challenges remain<br/>• Same level of effort | | **Option 2: Ownership change** | Transfer ownership to PMM, with:<br/>• RP Manager role → PMM<br/>• Tech Advisor → Digital Experience<br/>Other roles stay the same. | • **Shifts PMM visibility earlier for better GTM alignment**<br/>• Roles aligned to their anatomy components<br/>• Improved narrative through aligned marketing content ownership<br/>• Technical debt addressed by DEx ownership | • Requires PMM capacity to absorb RP Manager role<br/>• Unclear ROI remains<br/>• Same level of effort | | **Option 3: Deprecate RPs** | Deprecate release post with alternatives for dependencies | • Reduces total time investment<br/>• Focus on strategic content<br/>• Frees up PM time from volunteer role | • Loss of high-traffic artifact<br/>• Requires alternatives for dependencies<br/>• Requires change management | ### Option 1: Status quo with rotation added There are numerous issues with the current process, particularly around filling volunteer roles and making any improvements. If we continue with more or less the status quo, we must find improved methods to filling in roles: 1. RP manager: Have PLT member find someone within their department 2. Technical advisor: consider moving to DEx, for the time being: have RP manager find someone within their section/stage/group ### Option 2: Ownership change By moving program management of the release post to PMM, we shift left their visibility into what's coming and what the narrative should be. PMM would be involved earlier in determining what's in/out of the release post highlights, resulting in better alignment between the release post, blog post, and broader GTM motion. This alignment provides a more thoughtful and holistic user experience as well. ```mermaid flowchart TD A["PM/EM authors release post item"] --> B["PMM (Release Post Manager)<br/>reviews what's in/out,<br/>shapes narrative early"] B --> C["Release post published"] B --> D["Additional marketing material"] C --> E["What's New in-app"] C --> F["Release notes"] ``` Suggested [role](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/managers/) changes: 1. Release post manager > move to PMM. This gives PMM earlier visibility into what's shipping and ownership of the narrative. Aligns with Pragmatic's emphasis on the right market-facing roles owning positioning and messaging. 2. Messaging > deprecate and include into release post manager role, or have a second PMM team member 4. Technical Advisor > move to Digital Experience (DEx). DEx is already familiar with the `www-gitlab-com` repo and handles some of the updates. Roles with no changes: 1. Structural check > keep with TW, with rotation 2. PLT > keep with PLT, ensuring there is a rotation 3. PM/EM > keep role as authors of the release post items When implementing this option, relevant Product and Engineering team members would provide support to ensure a smooth transition. Depending on how far we shift things: {width=900 height=540} {width=900 height=541} ### Option 3: Deprecate in favour of marketing artifacts Marketing releases content all the time to highlight new features. There are a number of dependencies that currently rely on release post items, which we would need to replace with alternatives. Here are the dependencies and some example options: 1. MVP/contributor acknowledgement 1. move to community page 2. add to marketing release blog 1. what's new in-app items: 1. move to the code base, 1. pull from marketing's "what's new" site, 1. a single link to the "what's new" site with a brief list 1. `https://about.gitlab.com/releases/gitlab-com/` lists all items prior to official release 1. move to code base, delete when no longer needed 2. have items added to the "what's new" site 1. Release notes: https://gitlab.com/gitlab-org/gitlab/-/releases More research would need to be done if the alternatives are adequate substitutes for the release post. {width=900 height=537}