Add latest changes from gitlab-org/gitlab@13-1-stable-ee

8 files changed, 188 insertions, 104 deletions

diff --git a/doc/development/documentation/feature_flags.md b/doc/development/documentation/feature_flags.md
index 373c5a4ee7d..f3ce9ce3a83 100644
--- a/doc/development/documentation/feature_flags.md
+++ b/doc/development/documentation/feature_flags.md
@@ -43,10 +43,11 @@ For feature flags disabled by default, if they can be used by end users:
 
 - Say that it's disabled by default.
 - Say whether it's enabled on GitLab.com.
+- Say whether it can be enabled or disabled per-project.
 - Say whether it's recommended for production use.
 - Document how to enable and disable it.
 
-For example, for a feature disabled by default, disabled on GitLab.com, and
+For example, for a feature disabled by default, disabled on GitLab.com, can be enabled or disabled per-project, and
 not ready for production use:
 
 ````markdown
@@ -55,6 +56,7 @@ not ready for production use:
 > - [Introduced](link-to-issue) in GitLab 12.0.
 > - It's deployed behind a feature flag, disabled by default.
 > - It's disabled on GitLab.com.
+> - It's able to be enabled or disabled per-project
 > - It's not recommended for production use.
 > - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#anchor-to-section). **(CORE ONLY)**
 
@@ -65,18 +67,24 @@ not ready for production use:
 <Feature Name> is under development and not ready for production use. It is
 deployed behind a feature flag that is **disabled by default**.
 [GitLab administrators with access to the GitLab Rails console](../path/to/administration/feature_flags.md)
-can enable it for your instance.
+can enable it for your instance. <Feature Name> can be enabled or disabled per-project
 
 To enable it:
 
 ```ruby
+# Instance-wide
 Feature.enable(:<feature flag>)
+# or by project
+Feature.enable(:<feature flag>, Project.find(<project id>))
 ```
 
 To disable it:
 
 ```ruby
+# Instance-wide
 Feature.disable(:<feature flag>)
+# or by project
+Feature.disable(:<feature flag>, Project.find(<project id>))
 ```
 ````
 
@@ -88,10 +96,11 @@ For features that became enabled by default:
 
 - Say that it became enabled by default.
 - Say whether it's enabled on GitLab.com.
+- Say whether it can be enabled or disabled per-project.
 - Say whether it's recommended for production use.
 - Document how to disable and enable it.
 
-For example, for a feature initially deployed disabled by default, that became enabled by default, that is enabled on GitLab.com, and ready for production use:
+For example, for a feature initially deployed disabled by default, that became enabled by default, that is enabled on GitLab.com, that cannot be enabled or disabled per-project, and ready for production use:
 
 ````markdown
 # Feature Name
@@ -100,6 +109,7 @@ For example, for a feature initially deployed disabled by default, that became e
 > - It was deployed behind a feature flag, disabled by default.
 > - [Became enabled by default](link-to-issue) on GitLab 12.1.
 > - It's enabled on GitLab.com.
+> - It's not able to be enabled or disabled per-project
 > - It's recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(CORE ONLY)**
 
@@ -110,7 +120,7 @@ For example, for a feature initially deployed disabled by default, that became e
 <Feature Name> is under development but ready for production use.
 It is deployed behind a feature flag that is **enabled by default**.
 [GitLab administrators with access to the GitLab Rails console](..path/to/administration/feature_flags.md)
-can opt to disable it for your instance.
+can opt to disable it for your instance it cannot be enabled or disabled per-project.
 
 To disable it:
 
@@ -133,10 +143,11 @@ For features enabled by default:
 
 - Say it's enabled by default.
 - Say whether it's enabled on GitLab.com.
+- Say whether it can be enabled or disabled per-project.
 - Say whether it's recommended for production use.
 - Document how to disable and enable it.
 
-For example, for a feature enabled by default, enabled on GitLab.com, and ready for production use:
+For example, for a feature enabled by default, enabled on GitLab.com, cannot be enabled or disabled per-project, and ready for production use:
 
 ````markdown
 # Feature Name
@@ -144,6 +155,7 @@ For example, for a feature enabled by default, enabled on GitLab.com, and ready
 > - [Introduced](link-to-issue) in GitLab 12.0.
 > - It's deployed behind a feature flag, enabled by default.
 > - It's enabled on GitLab.com.
+> - It's not able to be enabled or disabled per-project
 > - It's recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(CORE ONLY)**
 
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 256d3f5d86c..f845a6ec592 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -59,7 +59,7 @@ However, anyone can contribute [documentation improvements](improvement-workflow
 ## Markdown and styles
 
 [GitLab docs](https://gitlab.com/gitlab-org/gitlab-docs) uses [GitLab Kramdown](https://gitlab.com/gitlab-org/gitlab_kramdown)
-as its Markdown rendering engine. See the [GitLab Markdown Guide](https://about.gitlab.com/handbook/engineering/ux/technical-writing/markdown-guide/) for a complete Kramdown reference.
+as its Markdown rendering engine. See the [GitLab Markdown Guide](https://about.gitlab.com/handbook/markdown-guide/) for a complete Kramdown reference.
 
 Adhere to the [Documentation Style Guide](styleguide.md). If a style standard is missing, you are welcome to suggest one via a merge request.
 
@@ -67,6 +67,41 @@ Adhere to the [Documentation Style Guide](styleguide.md). If a style standard is
 
 See the [Structure](styleguide.md#structure) section of the [Documentation Style Guide](styleguide.md).
 
+## Metadata
+
+To provide additional directives or useful information, we add metadata in YAML
+format to the beginning of each product documentation page.
+
+For example, the following metadata would be at the beginning of a product
+documentation page whose content is primarily associated with the Audit Events
+feature:
+
+```yaml
+---
+stage: Monitor
+group: APM
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+```
+
+The following list describes the YAML parameters in use:
+
+- `redirect_to`: The relative path and filename (with an `.md` extension) of the
+  location to which visitors should be redirected for a moved page.
+  [Learn more](#changing-document-location).
+- `stage`: The [Stage](https://about.gitlab.com/handbook/product/categories/#devops-stages)
+  to which the majority of the page's content belongs.
+- `group`: The [Group](https://about.gitlab.com/company/team/structure/#product-groups)
+  to which the majority of the page's content belongs.
+- `info`: The following line, which provides direction to contributors regarding
+  how to contact the Technical Writer associated with the page's Stage and
+  Group: `To determine the technical writer assigned to the Stage/Group
+  associated with this page, see
+  https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers`
+- `disqus_identifier`: Identifier for Disqus commenting system. Used to keep
+  comments with a page that's been moved to a new URL.
+  [Learn more](#redirections-for-pages-with-disqus-comments).
+
 ## Changing document location
 
 Changing a document's location requires specific steps to ensure that
@@ -133,10 +168,9 @@ Things to note:
   it in for `workflow/lfs/lfs_administration` and `lfs/lfs_administration`
   and will print the file and the line where this file is mentioned.
   You may ask why the two greps. Since [we use relative paths to link to
-  documentation](styleguide.md#links)
-  , sometimes it might be useful to search a path deeper.
+  documentation](styleguide.md#links), sometimes it might be useful to search a path deeper.
 - The `*.md` extension is not used when a document is linked to GitLab's
-  built-in help page, that's why we omit it in `git grep`.
+  built-in help page, which is why we omit it in `git grep`.
 - Use the checklist on the "Change documentation location" MR description template.
 
 ### Redirections for pages with Disqus comments
@@ -380,7 +414,7 @@ The following GitLab features are used among others:
 - [Multi project pipelines](../../ci/multi_project_pipeline_graphs.md)
 - [Review Apps](../../ci/review_apps/index.md)
 - [Artifacts](../../ci/yaml/README.md#artifacts)
-- [Specific Runner](../../ci/runners/README.md#locking-a-specific-runner-from-being-enabled-for-other-projects)
+- [Specific Runner](../../ci/runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
 - [Pipelines for merge requests](../../ci/merge_request_pipelines/index.md)
 
 ## Testing
@@ -477,7 +511,7 @@ This list does not limit what other linters you can add to your local documentat
 [markdownlint](https://github.com/DavidAnson/markdownlint) checks that Markdown
 syntax follows [certain rules](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#rules),
 and is used by the [`docs-lint` test](#testing) with a [configuration file](#markdownlint-configuration).
-Our [Documentation Style Guide](styleguide.md#markdown) and [Markdown Guide](https://about.gitlab.com/handbook/engineering/ux/technical-writing/markdown-guide/)
+Our [Documentation Style Guide](styleguide.md#markdown) and [Markdown Guide](https://about.gitlab.com/handbook/markdown-guide/)
 elaborate on which choices must be made when selecting Markdown syntax for GitLab
 documentation. This tool helps catch deviations from those guidelines.
 
@@ -498,7 +532,9 @@ If you wish to use a different configuration file, use the `-c` flag:
 markdownlint -c <config-file-name> 'doc/**/*.md'
 ```
 
-markdownlint can also be run from within text editors using [plugins/extensions](https://github.com/DavidAnson/markdownlint#related),
+##### Run markdownlint in an editor
+
+markdownlint can also be run as a linter within text editors using [plugins/extensions](https://github.com/DavidAnson/markdownlint#related),
 such as:
 
 - [Sublime Text](https://packagecontrol.io/packages/SublimeLinter-contrib-markdownlint)
@@ -524,7 +560,7 @@ four repositories that are the sources for <https://docs.gitlab.com>:
 
 By default all rules are enabled, so the configuration file is used to disable unwanted
 rules, and also to configure optional parameters for enabled rules as needed. You can
-also check [the issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/64352) that
+also check [the issue](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64352) that
 tracked the changes required to implement these rules, and details which rules were
 on or off when markdownlint was enabled on the docs.
 
@@ -546,11 +582,16 @@ and from GitLab's root directory (where `.vale.ini` is located), run:
 vale --glob='*.{md}' doc
 ```
 
-You can also
-[configure the text editor of your choice](https://errata-ai.github.io/vale/#local-use-by-a-single-writer)
-to display the results.
+Vale's error-level test results [are displayed](#testing) in CI pipelines.
+
+##### Run Vale in an editor
+
+You can run Vale as a linter within your text editor of choice, with:
+
+- The Sublime Text [`SublimeLinter-contrib-vale` plugin](https://packagecontrol.io/packages/SublimeLinter-contrib-vale)
+- The Visual Studio Code [`testthedocs.vale` extension](https://marketplace.visualstudio.com/items?itemName=testthedocs.vale)
 
-Vale's test results [are displayed](#testing) in CI pipelines.
+We don't use [Vale Server](https://errata-ai.github.io/vale/#using-vale-with-a-text-editor-or-another-third-party-application).
 
 ##### Disable a Vale test
 
diff --git a/doc/development/documentation/site_architecture/global_nav.md b/doc/development/documentation/site_architecture/global_nav.md
index 12190e2cb9e..71020e6054e 100644
--- a/doc/development/documentation/site_architecture/global_nav.md
+++ b/doc/development/documentation/site_architecture/global_nav.md
@@ -356,7 +356,7 @@ files.
 ```
 
 This also allows the nav to be displayed on other
-highest-level dirs (`/omnibus/`, `/runner/`, etc),
+highest-level directories (`/omnibus/`, `/runner/`, etc),
 linking them back to `/ee/`.
 
 The same logic is applied to all sections (`sec[:section_url]`),
diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md
index 56dd3821b1c..942b202a3ec 100644
--- a/doc/development/documentation/site_architecture/index.md
+++ b/doc/development/documentation/site_architecture/index.md
@@ -53,12 +53,12 @@ product, and all together are pulled to generate the docs website:
 - [GitLab Chart](https://gitlab.com/charts/gitlab/tree/master/doc)
 
 NOTE: **Note:**
-In September 2019, we [moved towards a single codebase](https://gitlab.com/gitlab-org/gitlab/issues/2952),
+In September 2019, we [moved towards a single codebase](https://gitlab.com/gitlab-org/gitlab/-/issues/2952),
 as such the docs for CE and EE are now identical. For historical reasons and
 in order not to break any existing links throughout the internet, we still
 maintain the CE docs (`https://docs.gitlab.com/ce/`), although it is hidden
 from the website, and is now a symlink to the EE docs. When
-[Pages supports redirects](https://gitlab.com/gitlab-org/gitlab-pages/issues/24),
+[Pages supports redirects](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/24),
 we will be able to remove this completely.
 
 ## Assets
@@ -107,13 +107,13 @@ The pipeline in the `gitlab-docs` project:
 
 Once a week on Mondays, a scheduled pipeline runs and rebuilds the Docker images
 used in various pipeline jobs, like `docs-lint`. The Docker image configuration files are
-located at <https://gitlab.com/gitlab-org/gitlab-docs/-/tree/master/dockerfiles>.
+located in the [Dockerfiles directory](https://gitlab.com/gitlab-org/gitlab-docs/-/tree/master/dockerfiles).
 
 If you need to rebuild the Docker images immediately (must have maintainer level permissions):
 
 CAUTION: **Caution**
 If you change the dockerfile configuration and rebuild the images, you can break the master
-pipeline in the main `gitlab` repo as well as in `gitlab-docs`. Create an image with
+pipeline in the main `gitlab` repository as well as in `gitlab-docs`. Create an image with
 a different name first and test it to ensure you do not break the pipelines.
 
 1. In [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs), go to **{rocket}** **CI / CD > Pipelines**.
@@ -173,7 +173,7 @@ we reference the array with a symbol (`:versions`).
 ## Bumping versions of CSS and JavaScript
 
 Whenever the custom CSS and JavaScript files under `content/assets/` change,
-make sure to bump their version in the frontmatter. This method guarantees that
+make sure to bump their version in the front matter. This method guarantees that
 your changes will take effect by clearing the cache of previous files.
 
 Always use Nanoc's way of including those files, do not hardcode them in the
@@ -207,22 +207,22 @@ If you don't specify `editor:`, the simple one is used by default.
 
 ## Algolia search engine
 
-The docs site uses [Algolia docsearch](https://community.algolia.com/docsearch/)
+The docs site uses [Algolia DocSearch](https://community.algolia.com/docsearch/)
 for its search function. This is how it works:
 
-1. GitLab is a member of the [docsearch program](https://community.algolia.com/docsearch/#join-docsearch-program),
+1. GitLab is a member of the [DocSearch program](https://community.algolia.com/docsearch/#join-docsearch-program),
    which is the free tier of [Algolia](https://www.algolia.com/).
 1. Algolia hosts a [DocSearch configuration](https://github.com/algolia/docsearch-configs/blob/master/configs/gitlab.json)
    for the GitLab docs site, and we've worked together to refine it.
-1. That [config](https://community.algolia.com/docsearch/config-file.html) is
+1. That [configuration](https://community.algolia.com/docsearch/config-file.html) is
    parsed by their [crawler](https://community.algolia.com/docsearch/crawler-overview.html)
    every 24h and [stores](https://community.algolia.com/docsearch/inside-the-engine.html)
-   the [docsearch index](https://community.algolia.com/docsearch/how-do-we-build-an-index.html)
+   the [DocSearch index](https://community.algolia.com/docsearch/how-do-we-build-an-index.html)
    on [Algolia's servers](https://community.algolia.com/docsearch/faq.html#where-is-my-data-hosted%3F).
-1. On the docs side, we use a [docsearch layout](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/layouts/docsearch.html) which
+1. On the docs side, we use a [DocSearch layout](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/layouts/docsearch.html) which
    is present on pretty much every page except <https://docs.gitlab.com/search/>,
    which uses its [own layout](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/layouts/instantsearch.html). In those layouts,
-   there's a JavaScript snippet which initiates docsearch by using an API key
+   there's a JavaScript snippet which initiates DocSearch by using an API key
    and an index name (`gitlab`) that are needed for Algolia to show the results.
 
 NOTE: **For GitLab employees:**
diff --git a/doc/development/documentation/site_architecture/release_process.md b/doc/development/documentation/site_architecture/release_process.md
index 13d6540fa35..d100ab8afa8 100644
--- a/doc/development/documentation/site_architecture/release_process.md
+++ b/doc/development/documentation/site_architecture/release_process.md
@@ -62,30 +62,15 @@ The single docs version must be created before the release merge request, but
 this needs to happen when the stable branches for all products have been created.
 
 1. Make sure you're in the root path of the `gitlab-docs` repository.
-1. Make sure your `master` is updated:
-
-   ```shell
-   git pull origin master
-   ```
-
 1. Run the Rake task to create the single version:
 
    ```shell
    ./bin/rake "release:single[12.0]"
    ```
 
-    A new `Dockerfile.12.0` should have been created and committed to a new branch.
-
-1. Edit `.gitlab-ci.yml` and replace the `BRANCH_` variables with their respective
-   upstream stable branch. For example, 12.6 would look like:
-
-   ```yaml
-   variables:
-     BRANCH_EE: '12-6-stable-ee'
-     BRANCH_OMNIBUS: '12-6-stable'
-     BRANCH_RUNNER: '12-6-stable'
-     BRANCH_CHARTS: '2-6-stable'
-   ```
+    A new `Dockerfile.12.0` should have been created and `.gitlab-ci.yml` should
+    have the branches variables updated into a new branch. They will be automatically
+    committed.
 
 1. Push the newly created branch, but **don't create a merge request**.
    Once you push, the `image:docker-singe` job will create a new Docker image
@@ -106,6 +91,9 @@ Visit `http://localhost:4000/12.0/` to see if everything works correctly.
 
 ### 3. Create the release merge request
 
+NOTE: **Note:**
+To be [automated](https://gitlab.com/gitlab-org/gitlab-docs/-/issues/750).
+
 Now it's time to create the monthly release merge request that adds the new
 version and rotates the old one:
 
@@ -161,7 +149,7 @@ versions:
 1. Run the Rake task that will create all the respective merge requests needed to
    update the dropdowns and will be set to automatically be merged when their
    pipelines succeed. The `release-X-Y` branch needs to be present locally,
-   otherwise the Rake task will fail:
+   and you need to have switched to it, otherwise the Rake task will fail:
 
    ```shell
    ./bin/rake release:dropdowns
diff --git a/doc/development/documentation/structure.md b/doc/development/documentation/structure.md
index d19383bee27..eadcedfaac0 100644
--- a/doc/development/documentation/structure.md
+++ b/doc/development/documentation/structure.md
@@ -34,7 +34,7 @@ For additional details on each, see the [template for new docs](#template-for-ne
 below.
 
 Note that you can include additional subsections, as appropriate, such as 'How it Works', 'Architecture',
-and other logical divisions such as pre- and post-deployment steps.
+and other logical divisions such as pre-deployment and post-deployment steps.
 
 ## Template for new docs
 
diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md
index 6d146051e13..9a93dbf4f94 100644
--- a/doc/development/documentation/styleguide.md
+++ b/doc/development/documentation/styleguide.md
@@ -96,7 +96,7 @@ Having a knowledge base in any form that is separate from the documentation woul
 
 All GitLab documentation is written using [Markdown](https://en.wikipedia.org/wiki/Markdown).
 
-The [documentation website](https://docs.gitlab.com) uses GitLab Kramdown as its Markdown rendering engine. For a complete Kramdown reference, see the [GitLab Markdown Kramdown Guide](https://about.gitlab.com/handbook/engineering/ux/technical-writing/markdown-guide/).
+The [documentation website](https://docs.gitlab.com) uses GitLab Kramdown as its Markdown rendering engine. For a complete Kramdown reference, see the [GitLab Markdown Kramdown Guide](https://about.gitlab.com/handbook/markdown-guide/).
 
 The [`gitlab-kramdown`](https://gitlab.com/gitlab-org/gitlab_kramdown)
 Ruby gem will support all [GFM markup](../../user/markdown.md) in the future. That is,
@@ -134,6 +134,8 @@ be ignored by markdownlint.
 
 In general, product names should follow the exact capitalization of the official names
 of the products, protocols, and so on.
+See [`.markdownlint.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.markdownlint.json)
+for the words tested for proper capitalization in GitLab documentation.
 
 Some examples fail if incorrect capitalization is used:
 
@@ -246,13 +248,14 @@ Do not include the same information in multiple places. [Link to a SSOT instead.
 GitLab documentation should be clear and easy to understand.
 
 - Be clear, concise, and stick to the goal of the documentation.
-- Write in US English with US grammar.
+- Write in US English with US grammar. (Tested in [`British.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/British.yml).)
 - Use inclusive language.
 
 ### Point of view
 
 In most cases, it’s appropriate to use the second-person (you, yours) point of view,
 because it’s friendly and easy to understand.
+(Tested in [`FirstPerson.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FirstPerson.yml).)
 
 <!-- How do we harmonize the second person in Pajamas with our first person plural in our doc guide? -->
 
@@ -272,10 +275,11 @@ because it’s friendly and easy to understand.
   - [GitLab Features](https://about.gitlab.com/features/). For example, Issue Board,
     Geo, and Runner.
   - GitLab [product tiers](https://about.gitlab.com/pricing/). For example, GitLab Core
-    and GitLab Ultimate.
+    and GitLab Ultimate. (Tested in [`BadgeCapitalization.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/BadgeCapitalization.yml).)
   - Third-party products. For example, Prometheus, Kubernetes, and Git.
   - Methods or methodologies. For example, Continuous Integration, Continuous
     Deployment, Scrum, and Agile.
+    (Tested in [`.markdownlint.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.markdownlint.json).)
 
     NOTE: **Note:**
     Some features are also objects. For example, "GitLab's Merge Requests support X" and
@@ -289,6 +293,7 @@ tenses, words, and phrases:
 - Avoid jargon.
 - Avoid uncommon words.
 - Don't write in the first person singular.
+  (Tested in [`FirstPerson.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FirstPerson.yml).)
   - Instead of "I" or "me," use "we," "you," "us," or "one."
   - When possible, stay user focused by writing in the second person ("you" or
     the imperative).
@@ -311,6 +316,7 @@ tenses, words, and phrases:
 - <!-- vale gitlab.LatinTerms = NO -->
   We discourage use of Latin abbreviations, such as "e.g.," "i.e.," or "etc.,"
   as even native users of English might misunderstand them.
+  (Tested in [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml).)
   - Instead of "i.e.," use "that is."
   - Instead of "e.g.," use "for example," "such as," "for instance," or "like."
   - Instead of "etc.," either use "and so on" or consider editing it out, since
@@ -319,6 +325,9 @@ tenses, words, and phrases:
 - Avoid using the word *currently* when talking about the product or its
   features. The documentation describes the product as it is, and not as it
   will be at some indeterminate point in the future.
+- Don't use profanity or obscenities. Doing so may negatively affect other
+  users and contributors, which is contrary to GitLab's value of
+  [diversity and inclusion](https://about.gitlab.com/handbook/values/#diversity-inclusion).
 
 ### Word usage clarifications
 
@@ -331,55 +340,55 @@ tenses, words, and phrases:
 
 ### Contractions
 
-- Use common contractions when it helps create a friendly and informal tone, especially in tutorials, instructional documentation, and [UIs](https://design.gitlab.com/content/punctuation/#contractions).
-
-| Do       | Don't     |
-|----------|-----------|
-| it's     | it is     |
-| can't    | cannot    |
-| wouldn't | would not |
-| you're   | you are   |
-| you've   | you have  |
-| haven't  | have not  |
-| don't    | do not    |
-| we're    | we are    |
-| that's   | that is   |
-| won't    | will not  |
+- Use common contractions when it helps create a friendly and informal tone, especially in tutorials, instructional documentation, and [UIs](https://design.gitlab.com/content/punctuation/#contractions). (Tested in [`Contractions.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Contractions.yml).)
+
+  | Do       | Don't     |
+  |----------|-----------|
+  | it's     | it is     |
+  | can't    | cannot    |
+  | wouldn't | would not |
+  | you're   | you are   |
+  | you've   | you have  |
+  | haven't  | have not  |
+  | don't    | do not    |
+  | we're    | we are    |
+  | that's   | that is   |
+  | won't    | will not  |
 
 - Avoid less common contractions:
 
-| Do           | Don't       |
-|--------------|-------------|
-| he would     | he'd        |
-| it will      | it'll       |
-| should have  | should've   |
-| there would  | there'd     |
+  | Do           | Don't       |
+  |--------------|-------------|
+  | he would     | he'd        |
+  | it will      | it'll       |
+  | should have  | should've   |
+  | there would  | there'd     |
 
 - Do not use contractions with a proper noun and a verb. For example:
 
-| Do                   | Don't               |
-|----------------------|---------------------|
-| GitLab is creating X | GitLab's creating X |
+  | Do                   | Don't               |
+  |----------------------|---------------------|
+  | GitLab is creating X | GitLab's creating X |
 
 - Do not use contractions when you need to emphasize a negative. For example:
 
-| Do                          | Don't                      |
-|-----------------------------|----------------------------|
-| Do **not** install X with Y | **Don't** install X with Y |
+  | Do                          | Don't                      |
+  |-----------------------------|----------------------------|
+  | Do **not** install X with Y | **Don't** install X with Y |
 
 - Do not use contractions in reference documentation. For example:
 
-| Do                                       | Don't                      |
-|------------------------------------------|----------------------------|
-| Do **not** set a limit greater than 1000 | **Don't** set a limit greater than 1000 |
-| For `parameter1`, the default is 10      | For `parameter1`, the default's 10     |
+  | Do                                       | Don't                      |
+  |------------------------------------------|----------------------------|
+  | Do **not** set a limit greater than 1000 | **Don't** set a limit greater than 1000 |
+  | For `parameter1`, the default is 10      | For `parameter1`, the default's 10     |
 
 - Avoid contractions in error messages. Examples:
 
-| Do                                       | Don't                      |
-|------------------------------------------|----------------------------|
-| Requests to localhost are not allowed    | Requests to localhost aren't allowed |
-| Specified URL cannot be used             | Specified URL can't be used          |
+  | Do                                       | Don't                      |
+  |------------------------------------------|----------------------------|
+  | Requests to localhost are not allowed    | Requests to localhost aren't allowed |
+  | Specified URL cannot be used             | Specified URL can't be used          |
 
 <!-- vale on -->
 
@@ -414,9 +423,9 @@ Check specific punctuation rules for [lists](#lists) below.
 | ---- | ------- |
 | Always end full sentences with a period. | _For a complete overview, read through this document._|
 | Always add a space after a period when beginning a new sentence. | _For a complete overview, check this doc. For other references, check out this guide._ |
-| Do not use double spaces. | --- |
+| Do not use double spaces. (Tested in [`SentenceSpacing.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SentenceSpacing.yml).) | --- |
 | Do not use tabs for indentation. Use spaces instead. You can configure your code editor to output spaces instead of tabs when pressing the tab key. | --- |
-| Use serial commas ("Oxford commas") before the final 'and/or' in a list. | _You can create new issues, merge requests, and milestones._ |
+| Use serial commas ("Oxford commas") before the final 'and/or' in a list. (Tested in [`OxfordComma.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/OxfordComma.yml).) | _You can create new issues, merge requests, and milestones._ |
 | Always add a space before and after dashes when using it in a sentence (for replacing a comma, for example). | _You should try this - or not._ |
 | Always use lowercase after a colon. | _Related Issues: a way to create a relationship between issues._ |
 
@@ -439,7 +448,7 @@ cp <your_source_directory> <your_destination_directory>
 - Always start list items with a capital letter, unless they are parameters or commands
   that are in backticks, or similar.
 - Always leave a blank line before and after a list.
-- Begin a line with spaces (not tabs) to denote a [nested subitem](#nesting-inside-a-list-item).
+- Begin a line with spaces (not tabs) to denote a [nested sub-item](#nesting-inside-a-list-item).
 
 ### Ordered vs. unordered lists
 
@@ -599,7 +608,7 @@ that is best described by a matrix, tables are the best choice for use.
 
 ### Creation guidelines
 
-Due to accessibility and scanability requirements, tables should not have any
+Due to accessibility and scannability requirements, tables should not have any
 empty cells. If there is no otherwise meaningful value for a cell, consider entering
 *N/A* (for 'not applicable') or *none*.
 
@@ -648,7 +657,7 @@ For other punctuation rules, please refer to the
   links shift too, which eventually leads to dead links. If you think it is
   compelling to add numbers in headings, make sure to at least discuss it with
   someone in the Merge Request.
-- [Avoid using symbols and special chars](https://gitlab.com/gitlab-org/gitlab-docs/issues/84)
+- [Avoid using symbols and special characters](https://gitlab.com/gitlab-org/gitlab-docs/-/issues/84)
   in headers. Whenever possible, they should be plain and short text.
 - Avoid adding things that show ephemeral statuses. For example, if a feature is
   considered beta or experimental, put this information in a note, not in the heading.
@@ -719,6 +728,7 @@ We include guidance for links in the following categories:
 - How to set up [criteria](#basic-link-criteria) for configuring a link.
 - What to set up when [linking to a `help`](../documentation/index.md#linking-to-help) page.
 - How to set up [links to internal documentation](#links-to-internal-documentation) for cross-references.
+- How to set up [links to external documentation](#links-to-external-documentation) for authoritative sources.
 - When to use [links requiring permissions](#links-requiring-permissions).
 - How to set up a [link to a video](#link-to-video).
 - How to [include links with version text](#text-for-documentation-requiring-version-text).
@@ -771,6 +781,12 @@ To link to internal documentation:
 NOTE: **Note**:
 Using the Markdown extension is necessary for the [`/help`](index.md#gitlab-help) section of GitLab.
 
+### Links to external documentation
+
+When describing interactions with external software, it's often helpful to include links to external
+documentation. When possible, make sure that you are linking to an **authoritative** source.
+For example, if you're describing a feature in Microsoft's Active Directory, include a link to official Microsoft documentation.
+
 ### Links requiring permissions
 
 Don't link directly to:
@@ -793,7 +809,7 @@ Instead:
 Example:
 
 ```markdown
-For more information, see the [confidential issue](../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-foss/issues/<issue_number>`.
+For more information, see the [confidential issue](../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-foss/-/issues/<issue_number>`.
 ```
 
 ### Link to specific lines of code
@@ -1040,11 +1056,11 @@ of language classes available.
 | `xml`                   |                                                                              |
 | `yaml`                  | Alias: `yml`.                                                                |
 
-For a complete reference on code blocks, check the [Kramdown guide](https://about.gitlab.com/handbook/engineering/ux/technical-writing/markdown-guide/#code-blocks).
+For a complete reference on code blocks, check the [Kramdown guide](https://about.gitlab.com/handbook/markdown-guide/#code-blocks).
 
 ## GitLab SVG icons
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-docs/issues/384) in GitLab 12.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-docs/-/issues/384) in GitLab 12.7.
 
 You can use icons from the [GitLab SVG library](https://gitlab-org.gitlab.io/gitlab-svgs/) directly
 in the documentation.
@@ -1359,7 +1375,35 @@ versions back, you can consider removing the text if it's irrelevant or confusin
 For example, if the current major version is 12.x, version text referencing versions of GitLab 8.x
 and older are candidates for removal if necessary for clearer or cleaner docs.
 
-## Product badges
+## Products and features
+
+Refer to the information in this section when describing products and features
+within the GitLab product documentation.
+
+### Avoid line breaks in names
+
+When entering a product or feature name that includes a space (such as
+GitLab Community Edition) or even other companies' products (such as
+Amazon Web Services), be sure to not split the product or feature name across
+lines with an inserted line break. Splitting product or feature names across
+lines makes searching for these items more difficult, and can cause problems if
+names change.
+
+For example, the followng Markdown content is *not* formatted correctly:
+
+```markdown
+When entering a product or feature name that includes a space (such as GitLab
+Community Edition), don't split the product or feature name across lines.
+```
+
+Instead, it should appear similar to the following:
+
+```markdown
+When entering a product or feature name that includes a space (such as
+GitLab Community Edition), don't split the product or feature name across lines.
+```
+
+### Product badges
 
 When a feature is available in EE-only tiers, add the corresponding tier according to the
 feature availability:
@@ -1399,7 +1443,7 @@ For example:
 The absence of tiers' mentions mean that the feature is available in GitLab Core,
 GitLab.com Free, and all higher tiers.
 
-### How it works
+#### How it works
 
 Introduced by [!244](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/244),
 the special markup `**(STARTER)**` will generate a `span` element to trigger the
@@ -1608,7 +1652,7 @@ Rendered example:
 - Wherever needed use this personal access token: `<your_access_token>`.
 - Always put the request first. `GET` is the default so you don't have to
   include it.
-- Use double quotes to the URL when it includes additional parameters.
+- Wrap the URL in double quotes (`"`).
 - Prefer to use examples using the personal access token and don't pass data of
   username and password.
 
@@ -1686,9 +1730,8 @@ Use `%2F` for slashes (`/`).
 #### Pass arrays to API calls
 
 The GitLab API sometimes accepts arrays of strings or integers. For example, to
-restrict the sign-up e-mail domains of a GitLab instance to `*.example.com` and
-`example.net`, you would do something like this:
+exclude specific users when requesting a list of users for a project, you would do something like this:
 
 ```shell
-curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --data "domain_whitelist[]=*.example.com" --data "domain_whitelist[]=example.net" https://gitlab.example.com/api/v4/application/settings
+curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --data "skip_users[]=<user_id>" --data "skip_users[]=<user_id>" https://gitlab.example.com/api/v4/projects/<project_id>/users
 ```
diff --git a/doc/development/documentation/workflow.md b/doc/development/documentation/workflow.md
index ab6200155bf..c3e15cb1b2b 100644
--- a/doc/development/documentation/workflow.md
+++ b/doc/development/documentation/workflow.md
@@ -54,7 +54,7 @@ To update GitLab documentation:
 1. Follow the described standards and processes listed on the page, including:
    - The [Structure and template](structure.md) page.
    - The [Style Guide](styleguide.md).
-   - The [Markdown Guide](https://about.gitlab.com/handbook/engineering/ux/technical-writing/markdown-guide/).
+   - The [Markdown Guide](https://about.gitlab.com/handbook/markdown-guide/).
 1. Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
 
 TIP: **Tip:**
@@ -104,7 +104,7 @@ The process involves the following:
   - Ensure the appropriate labels are applied, including any required to pick a merge request into
     a release.
   - Ensure that, if there has not been a Technical Writer review completed or scheduled, they
-    [create the required issue](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Doc%20Review), assign to the Technical Writer of the given stage group,
+    [create the required issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Doc%20Review), assign to the Technical Writer of the given stage group,
     and link it from the merge request.
 
 The process is reflected in the **Documentation**
@@ -113,14 +113,14 @@ The process is reflected in the **Documentation**
 ## Other ways to help
 
 If you have ideas for further documentation resources please
-[create an issue](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Documentation)
+[create an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Documentation)
 using the Documentation template.
 
 ## Post-merge reviews
 
 If not assigned to a Technical Writer for review prior to merging, a review must be scheduled
 immediately after merge by the developer or maintainer. For this,
-create an issue using the [Doc Review description template](https://gitlab.com/gitlab-org/gitlab/issues/new?issuable_template=Doc%20Review)
+create an issue using the [Doc Review description template](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Doc%20Review)
 and link to it from the merged merge request that introduced the documentation change.
 
 Circumstances where a regular pre-merge Technical Writer review might be skipped include: