Technical Writing workflow

On this page

This document explains the workflow of the Technical Writing team. Consider it an extension of the Engineering workflow which you should be familiar with. For the workflow that applies to everyone please see PROCESS.md.

Process

In order to avoid situations where a feature slips through without documentation, there must be a clear, defined process.

A checklist is present in the MR template to make sure that documentation is part of the MR, but sometimes there are some legitimate reasons to defer documentation from the initial MR which then makes it easy to get lost.

Two things you need to remember:

  1. For every release cycle, every issue that introduces a new feature and requires new documentation to be added or changed, must have the Documentation label assigned along with one of the priority labels.
  2. If the implementation MR for some reason cannot have docs, only merge the MR if there is a new issue created that is tracking the docs needed. The new issue should have the appropriate milestone, assignee and at least both the Documentation and Deliverable labels, which is important so that the issue is shown in the Documentation issue board. Make sure to link back to the implementation MR and the initial issue for a reference. This will save time from searching information needed to write the docs.

The GitLab.org group issue board can then be used to schedule what issues to work on.

Priority and scheduling

There are various types of issues you are called to work on:

Below is the current priority of scheduling issues:

  1. Documentation for the current release (consult the board)
  2. Documentation issues with the customer label
  3. Everything else

Workflow labels

Labels are described in our Contribution guide.

Product development timeline

The documentation should be ready by the 8th for the kickoff call and the link added to the release post of the upcoming release. For more information on the product development timeline, see the Engineering handbook.