Update improvement-workflow, remove Support-specific items

1 files changed, 14 insertions, 28 deletions

diff --git a/doc/development/documentation/improvement-workflow.md b/doc/development/documentation/improvement-workflow.md
index 62f5061e1fc..9d13c81449e 100644
--- a/doc/development/documentation/improvement-workflow.md
+++ b/doc/development/documentation/improvement-workflow.md
@@ -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
 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
-regularly update docs when handling support cases, where a doc update would
-enable users to accomplish tasks successfully on their own in the future,
-preventing problems and the need to contact Support.
+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.
 
-Support and others should use a docs-first approach; rather than directly
-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
+## 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
@@ -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
 yield a useful result.
 
-### Who can merge
-
-Who can and should merge depends on the type of update.
+## Merging
 
-- **If a simple troubleshooting item, minor correction, or other added note/caveat**,
-and if the content is known by the author to be accurate or has been reviewed
-by SME, it can be merged by anyone with master permissions (e.g. a Support
-Manager). However, requests for technical writer review or assistance are
-always welcome.
+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 creating/deleting/moving a page or page subsection, or other larger doc
-updates, including more extensive troubleshooting steps**, we require a technical
-writer review. However, you can always link a user to your MR before it is merged.
+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
+## 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.
-<!-- TODO: Update and document issue and MR description templates as part of the process. -->