Content Websites

Overview

This area has traditionally been referred to as “the handbook”, but over time has grown in scope to include multiple sites, projects, repos, and types of content.

Therefore, we are using the term “content websites” here to avoid ambiguity and properly frame discussions around this scope of responsibility.

See our direction page for detailed plans.

Team Structure

The maintainer of this page (as indicated in the sidebar) is considered the DRI for GitLab’s “content websites”. At present this team falls under the Chief of Staff Team to the CEO and the job family for engineers working on these projects is defined as a specialty.

This page further documents the scope and responsibilities of the DRI and their engineering reports.

What are the content websites?

1. The public about.gitlab.com website:
   1. While often referred to as “the handbook”, this website also serves a wide variety of other content including the handbook, the blog, releases, category direction pages, many marketing pages, and other uncategorized documentation for various areas of GitLab.
   2. about.gitlab.com is primarily backed by the gitlab-com/www-gitlab-com project and repo.
   3. Some of the content for about.gitlab.com is also backed by the gitlab-com/marketing/digital-experience/buyer-experience project and repo, such as small-business and enterprise. The plan is to migrate more content from the gitlab-com/www-gitlab-com project to the gitlab-com/marketing/digital-experience/buyer-experience project.
2. The “Internal Handbook” at internal-handbook.gitlab.io:
   1. This website contains content that falls into the not public category. More details are available in the Internal Handbook usage page
   2. The Internal Handbook is backed by the internal-handbook/internal-handbook.gitlab.io project and repo.

What MAY be content websites?

These sites require further investigation, evaluation of current ownership, and a clearer definition of responsibilities:

• The compensation calculator at comp-calculator.gitlab.net
• Project SuperSonics at gitlab-com.gitlab.io/licensing/
• People Operations aka POPS internal handbook

What are NOT content websites?

• The gitlab.com SaaS site.
• The docs.gitlab.com product documentation site.
• Any other GitLab-managed or GitLab-owned website other than what is described above

Content Websites DRI

1. Responsible for all aspects of these content websites, including:
   1. All business critical content for the content sites.
   2. All shared and supporting aspects of the content sites, including infrastructure, code, architecture, projects, security, CI/CD, builds, deployments, upgrades, performance, scalability, metrics, monitoring, etc.
   3. Triaging all issues and support requests, and delegating them to other responsible groups as appropriate.
   4. Providing on-call support for high-priority incidents or outages, and escalating to infrastructure, reliability engineering, or other groups as appropriate.
   5. Project management, planning, and reporting for the above.
2. The Digital Experience team under Michael Preuss also has responsibility for the marketing-related areas of the site. These areas include the gitlab-com/marketing/digital-experience/buyer-experience project and repo, as well as other content. The exact areas are still not fully defined, and this should also be clarified as part of the definition of DRIs.

Support process for content websites

There is currently information describing differing support policies for the content websites in various places, and some of this info may be inconsistent or outdated. For example, the “Handbook On-Call” page, or the Handbook Support page.

All of this information should be cleaned up and consolidated when a final DRI is assigned. In the meantime, this is the process to obtain support:

1. Simple git or technical questions with MRs conflicts, markdown formatting errors, linting errors, pipeline failures, etc. can be asked in the #mr-buddies slack channel.
2. High-priority questions regarding broken master, outages, security concerns, etc. can be asked in the #handbook-escalation channel. See the existing “Handbook On-Call - When to escalate an issue” section for what types of issues are appropriate to be asked in this channel.
   1. If there is not an existing issue, you may be asked to create one in the www-gitlab-com project for tracking and prioritization purposes.
   2. Please use the Content Websites Support (about.gitlab.com or internal-handbook.gitlab.io) issue template.
   3. Make sure to included the ~content-websites-support label.
   4. Link to the new issue in #handbook-escalation for triage.
3. For other topics not falling under either of the two above categories, for example, a feature request, a general question about content, etc.:
   1. You can start by asking a question or discussing it in the #handbook channel for the public about.gitlab.com site, or in the #internal-handbook for the Internal Handbook.
   2. If you determine action is needed (and you can’t fix it yourself with an MR), open a new issue in the www-gitlab-com project. If this is related to the internal handbook, you can make the issue confidential as necessary.
   3. Apply the ~content-websites-support label.
   4. Link to the issue in #handbook or #internal-handbook for triage.