gitlab-org--gitlab-foss/doc/development/documentation/improvement-workflow.md

---
description: How to improve GitLab's documentation.
---

# Other documentation updates

Anyone can contribute a merge request or create an issue for GitLab's documentation.

This page covers the process for general contributions to GitLab's docs (other
than those which arise from release-related feature updates) can be found on the
documentation guidelines page under [other documentation contributions](index.md#other-documentation-contributions).

## Who updates the docs

Anyone can contribute! You can create a merge request with documentation
when you find errors or other room for improvement, or have an idea for all-new
documentation that would help a GitLab user or admin achieve or optimize their
DevOps workflows.

## Content: what belongs in the docs

In docs, we share any and all helpful info/processes/tips with customers, but
warn them in specific terms about the potential ramifications of any mentioned
actions. There is no reason to withhold 'risky' steps and store them in another
location; simply include them along with the rest of the docs, with all necessary
detail including specific warnings and caveats.

A `Troubleshooting` section in doc pages is part of the default [template](structure.md)
for a new page, and can freely be added to any page.

These guidelines help toward the goal of having every user's search of documentation
yield a useful result.

## Merging

Anyone with master access to the affected GitLab project can merge documentation changes.
This person must make a good-faith effort to ensure that the content is clear
(sufficiently easy for the intended audience to navigate and understand) and
that it meets the [Documentation Guidelines](index.md) and [Style Guide](styleguide.md).

If the author or reviewer has any questions, or would like a techncial writer's review
before merging, mention the writer who is assigned to the relevant [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).

## Other ways to help

If you have ideas for further documentation resources that would be best
considered/handled by technical writers, devs, and other SMEs, please create an issue.