61 lines
2.6 KiB
Markdown
61 lines
2.6 KiB
Markdown
---
|
|
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.
|
|
|
|
## How to update the docs
|
|
|
|
Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
|
|
|
|
## 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.
|
|
|
|
Any content that is relevant to users or admins may be included. You can freely
|
|
include presentations, videos, etc.; no matter who it was originally written for,
|
|
if it is helpful to any of our audiences, we can include it.
|
|
|
|
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).
|
|
|
|
## Technical Writer Review
|
|
|
|
The technical writing team reviews changes after they are merged, unless one of
|
|
the technical writers already reviewed prior to the merge.
|
|
|
|
## 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.
|