index.md

info: For assistance with this Style Guide page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
stage: none
group: unassigned
description: 'Writing styles, markup, formatting, and other standards for GitLab Documentation.'

Documentation Style Guide

This document defines the standards for GitLab documentation, including grammar, formatting, and more. For guidelines on specific words, see the word list.

For style questions, mention @tw-style in an issue or merge request. If you have access to the GitLab Slack workspace, use the #docs-processes channel.

The GitLab voice

The GitLab brand guidelines define the voice used by the larger organization.

Building on that guidance, the voice in the GitLab documentation strives to be concise, direct, and precise. The goal is to provide information that's easy to search and scan.

The voice in the documentation should be conversational but brief, friendly but succinct.

Documentation is the single source of truth (SSoT)

The GitLab documentation is the SSoT for all product information related to implementation, use, and troubleshooting. The documentation evolves continuously. It is updated with new products and features, and with improvements for clarity, accuracy, and completeness.

This policy prevents information silos, making it easier to find information about GitLab products. It also informs decisions about the kinds of content included in the documentation.

Topic types

GitLab uses topic types to organize the product documentation.

Topic types help users digest information more quickly. They also help address these issues:

• Content is hard to find. The GitLab docs are comprehensive and include a large amount of useful information. Topic types create repeatable patterns that make the content easier to scan and parse.
• Content is often written from the contributor's point of view. The GitLab docs are written by a variety of contributors. Topic types (tasks, specifically) help put information into a format that is geared toward helping others, rather than documenting how a feature was implemented.

Docs-first methodology

The product documentation should be a complete and trusted resource.

• If the answer to a question exists in documentation, share the link to the documentation instead of rephrasing the information.
• When you encounter information that's not available in GitLab documentation, create a merge request (MR) to add the information to the documentation. Then share the MR to communicate the information.

The more we reflexively add information to the documentation, the more the documentation helps others efficiently accomplish tasks and solve problems.

Writing for localization