Going forward, all changes on the marketing site (about.gitlab.com) must follow an approval process prior to merging in changes on the website.
The lack of an approval process for changes going to production on GitLab’s Marketing site creates a risk for our business because, as it stands today, anyone can push a change live to our site at any time (details of risk outlined in the Problem Statement below). We are introducing a review process for any contributions going live on the Marketing Site.
GitLab’s Marketing site has undergone significant changes over the last two years. GitLab’s Marketing team has collaborated on a strategic user flow and is working on specific user journeys that drive our business metrics. As such, we require approvals and controls in place to ensure that all contributions to the Marketing site support ongoing efforts. There are currently no controls or permissions in place, which creates a risk to our business performance. Risk in this situation can take the form of broken analytics data, inconsistent brand messaging, negative impact on SEO ranking, and potential legal issues.
At its peak, GitLab’s Marketing site contained over 3500 pages. Many of these pages receive little to no traffic and have not been updated or deleted since they were created. One can assume the root cause for this bloat is a lack of accountability due to the lack of approvals to ensure content is added or modified with intent and coordination in collaboration with cross-functional teams.
Another example is cases where we have several similar pages that may make sense from an inside-out perspective, but from a customer-centric perspective, they confuse our prospective customers. Example: CI/CD Pages:
A byproduct of the uncontrolled increase in pages is the unintended effect of diluting the value of the data we collect from Google Analytics. With so many pages receiving little traffic and providing little value to our prospective customers, we struggle to get concentrated data on core pages.
The codeowners feature was launched on GitLab in 2019, and this requirement was identified with support from the previous CMO but was never actioned: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/4085
The goal of putting controls and approvals in place is to ensure that all changes to the GitLab Marketing site (about.gitlab.com, not including about.gitlab.com/handbook/* or about.gitlab.com/direction/*) support the defined objectives of GitLab’s Marketing team. We will operate the same way as our Product team in that the appropriate people approve all MRs before going into production.
The approval process will increase the consistency of our Marketing site while ensuring ongoing initiatives are not at risk of being disrupted due to unapproved changes going live to production. The approval process will also increase visibility and collaboration to provide a customer-centric and coordinated effort for those looking to improve GitLab’s Marketing site.
We do not want to compromise GitLab’s everyone can contribute mission. Our strategy is to implement a minimal approvals process. Currently, an MR goes live straight to production; this change results in a contribution taking the form of an AB Test proposal (issue) or for an MR to be reviewed before being merged into production.
The Digital Experience team has set up a project for AB Test proposals as a repo: https://gitlab.com/gitlab-com/marketing/digital-experience/ab-testing. Anyone can contribute an issue using the AB Testing issue template (template in progress).
Not everything needs to be an AB Test proposal; we still prioritize MRs as defined in the handbook: everything starts with an MR.
We will have four approval flows, from minor to major change. The goal is for a member of GitLab’s Digital Experience team always to review an MR before it goes live on the Buyer Experience repo or key marketing pages in the www-gitlab-com repo.
dex-approval::1-minordex-approval::2-standarddex-approval::3-key-pagedex-approval::4-legalOnce an MR is ready for review, approval outlined in the above sequence must occur to merge an MR into production.
All pages of the Marketing site (about.gitlab.com minus /handbook) are included in the requirement of this new approval process.
When creating a merge request in the Buyer Experience Repository (where we are migrating our marketing pages), please use the marketing-site-change template.
Please describe the change and link any relevant issues.
The MR will have dex-approval::2-standard automatically applied, but please update it to one of the following, based to the approval levels above.
Depending on which label is used, you may tag the following people as a Reviewer on this MR:
@gitlab-com/marketing/digital-experience in a comment. This will tag the Digital Experience Leadership team using @gitlab-com/marketing/digital-experience, and they can review. When in doubt, tag @mpreuss as a reviewer.@mpreuss and he can loop in the legal team.For changes to Support-related pages, please tag @jcolyer for review.