---
layout: handbook-page-toc
title: "Technical Writing workflows"
---

## On this page
{:.no_toc .hidden-md .hidden-lg}

- TOC
{:toc .hidden-md .hidden-lg}

This document explains the workflows of the Technical Writing team.

These processes work in conjunction with the [Product development flow](/handbook/product-development-flow/),
[Product designer workflow](https://about.gitlab.com/handbook/engineering/ux/ux-designer), and
[Engineering workflow](/handbook/engineering/workflow/), and the broader information about
contributing to GitLab found in [PROCESS.md](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md).

## Documentation authoring and review

These processes are open to all GitLab contributors, so they are documented
within GitLab's documentation itself.

See the [Documentation process](https://docs.gitlab.com/ee/development/documentation/workflow.html) page.

## UI text

### Planning and authoring

A Product Designer should consult with the Technical Writer for their stage group when planning to add
or change substantial text within the UI, such as a phrase of explanatory microcopy or a link to documentation.

The technical writer can offer an initial review of any ideas, plans, or actual text, and can be asked to
draft text when provided with information on the context and goals of the text. Context may include
detail on the scenarios in which the text would appear (for example, to all users viewing the feature
or only under certain conditions), and the information to convey, which typically answers
one or more of the questions:

- What does this do?
- How do I use it?
- Why should I care?

### MR Reviews

Once the merge request is created, all changes and additions to text in the UI *must* be reviewed by the Technical Writer.
These may include labels (buttons, menus, column headers, UI sections) or any phrases that may be displayed within the UI,
such as user-assistance microcopy or error messages.

### Resources

Technical writers should familiarize themselves with these Pajamas Design System pages, use them when working with UI Copy, and contribute improvements to them if possible: 

- [Voice and Tone](https://design.gitlab.com/content/voice-tone)
- [Terminology](https://design.gitlab.com/content/terminology)
- [Punctuation](https://design.gitlab.com/content/punctuation), using them when working

Additional information about composing and reviewing UI text:

- "[Copy That: Helping your Users Succeed with Effective Product Copy](https://www.youtube.com/watch?v=M_Q1RO0ky2c)", a talk by Sarah Day.

## Release posts

The technical writer for each [stage group](https://about.gitlab.com/handbook/product/categories/) 
is a reviewer of their group's [feature blocks](https://about.gitlab.com/handbook/marketing/blog/release-posts/#feature-blocks) authored by the Product Manager.

For each release, a single technical writer is also assigned to the Release Post [Structural Check](https://about.gitlab.com/handbook/marketing/blog/release-posts/#structural-check).

## Workflow labels

Labels are described in the Development documentation [Issues workflow](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/contributing/issue_workflow.md) page.