Commit 89bd8a15 authored by Mike Lewis's avatar Mike Lewis

Update improvement-workflow, remove Support-specific items

parent 9bfd4554
...@@ -10,23 +10,14 @@ This page covers the process for general contributions to GitLab's docs (other ...@@ -10,23 +10,14 @@ 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 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). documentation guidelines page under [other documentation contributions](index.md#other-documentation-contributions).
## Role of Support in GitLab Documentation ## Who updates the docs
GitLab support engineers are key contributors to GitLab docs. They should Anyone can contribute! You can create a merge request with documentation
regularly update docs when handling support cases, where a doc update would when you find errors or other room for improvement, or have an idea for all-new
enable users to accomplish tasks successfully on their own in the future, documentation that would help a GitLab user or admin achieve or optimize their
preventing problems and the need to contact Support. DevOps workflows.
Support and others should use a docs-first approach; rather than directly ## Content: what belongs in the docs
responding to a customer with a solution, where possible/applicable, first produce
an MR for a new or updated doc and then link it in the customer communication /
forum reply. If the MR can get merged immediately, even better—just link to the
live doc instead.
Generally, support engineers can contribute to docs in the same way as other
improvements are made, but this section contains additional Support-specific tips.
### Content: what belongs in the docs
In docs, we share any and all helpful info/processes/tips with customers, but 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 warn them in specific terms about the potential ramifications of any mentioned
...@@ -40,22 +31,17 @@ for a new page, and can freely be added to any page. ...@@ -40,22 +31,17 @@ 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 These guidelines help toward the goal of having every user's search of documentation
yield a useful result. yield a useful result.
### Who can merge ## Merging
Who can and should merge depends on the type of update.
- **If a simple troubleshooting item, minor correction, or other added note/caveat**, Anyone with master access to the affected GitLab project can merge documentation changes.
and if the content is known by the author to be accurate or has been reviewed This person must make a good-faith effort to ensure that the content is clear
by SME, it can be merged by anyone with master permissions (e.g. a Support (sufficiently easy for the intended audience to navigate and understand) and
Manager). However, requests for technical writer review or assistance are that it meets the [Documentation Guidelines](index.md) and [Style Guide](styleguide.md).
always welcome.
- **If creating/deleting/moving a page or page subsection, or other larger doc If the author or reviewer has any questions, or would like a techncial writer's review
updates, including more extensive troubleshooting steps**, we require a technical before merging, mention the writer who is assigned to the relevant [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
writer review. However, you can always link a user to your MR before it is merged.
### Other ways to help ## Other ways to help
If you have ideas for further documentation resources that would be best 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. considered/handled by technical writers, devs, and other SMEs, please create an issue.
<!-- TODO: Update and document issue and MR description templates as part of the process. -->
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment