Add latest changes from gitlab-org/gitlab@15-3-stable-eev15.3.0-rc42

10 files changed, 246 insertions, 348 deletions

diff --git a/doc/development/documentation/restful_api_styleguide.md b/doc/development/documentation/restful_api_styleguide.md
index 92c34c01e5d..bf1461a810d 100644
--- a/doc/development/documentation/restful_api_styleguide.md
+++ b/doc/development/documentation/restful_api_styleguide.md
@@ -5,7 +5,7 @@ group: unassigned
 description: 'Writing styles, markup, formatting, and other standards for the GitLab RESTful APIs.'
 ---
 
-# RESTful API
+# Documenting REST API resources
 
 REST API resources are documented in Markdown under
 [`/doc/api`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc/api). Each
@@ -104,6 +104,9 @@ for the section. For example:
 > `widget_message` [introduced](<link-to-issue>) in GitLab 14.3.
 ```
 
+If the API or attribute is deployed behind a feature flag,
+[include the feature flag information](feature_flags.md) in the version history.
+
 ## Deprecations
 
 To document the deprecation of an API endpoint, follow the steps to
diff --git a/doc/development/documentation/site_architecture/deployment_process.md b/doc/development/documentation/site_architecture/deployment_process.md
index 5203ca52922..5f6076f3195 100644
--- a/doc/development/documentation/site_architecture/deployment_process.md
+++ b/doc/development/documentation/site_architecture/deployment_process.md
@@ -142,6 +142,20 @@ graph LR
   B--"Unpacked documentation uploaded"-->C
 ```
 
+### Manually deploy to production
+
+GitLab Docs is deployed to production whenever the `Build docs.gitlab.com every 4 hours` scheduled pipeline runs. By
+default, this pipeline runs every four hours.
+
+Maintainers can [manually](../../../ci/pipelines/schedules.md#run-manually) run this pipeline to force a deployment to
+production:
+
+1. Go to the [scheduled pipelines](https://gitlab.com/gitlab-org/gitlab-docs/-/pipeline_schedules) for `gitlab-docs`.
+1. Next to `Build docs.gitlab.com every 4 hours`, select **Play** (**{play}**).
+
+The updated documentation is available in production after the `pages` and `pages:deploy` jobs
+complete in the new pipeline.
+
 ## Docker files
 
 The [`dockerfiles` directory](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/dockerfiles/) contains all needed
@@ -150,10 +164,10 @@ Dockerfiles to build and deploy <https://docs.gitlab.com>. It is heavily inspire
 
 | Dockerfile                                                                                                                 | Docker image                  | Description                                                                                                                                                                                                                                                                           |
 |:---------------------------------------------------------------------------------------------------------------------------|:------------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [`Dockerfile.bootstrap`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/dockerfiles/Dockerfile.bootstrap)             | `gitlab-docs:bootstrap`       | Contains all the dependencies that are needed to build the website. If the gems are updated and `Gemfile{,.lock}` changes, the image must be rebuilt.                                                                                                                                 |
-| [`Dockerfile.builder.onbuild`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/dockerfiles/Dockerfile.builder.onbuild) | `gitlab-docs:builder-onbuild` | Base image to build the docs website. It uses `ONBUILD` to perform all steps and depends on `gitlab-docs:bootstrap`.                                                                                                                                                                  |
-| [`Dockerfile.nginx.onbuild`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/dockerfiles/Dockerfile.nginx.onbuild)     | `gitlab-docs:nginx-onbuild`   | Base image to use for building documentation archives. It uses `ONBUILD` to perform all required steps to copy the archive, and relies upon its parent `Dockerfile.builder.onbuild` that is invoked when building single documentation archives (see the `Dockerfile` of each branch) |
-| [`Dockerfile.archives`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/dockerfiles/Dockerfile.archives)               | `gitlab-docs:archives`        | Contains all the versions of the website in one archive. It copies all generated HTML files from every version in one location.                                                                                                                                                       |
+| [`bootstrap.Dockerfile`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/dockerfiles/bootstrap.Dockerfile)             | `gitlab-docs:bootstrap`       | Contains all the dependencies that are needed to build the website. If the gems are updated and `Gemfile{,.lock}` changes, the image must be rebuilt.                                                                                                                                 |
+| [`builder.onbuild.Dockerfile`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/dockerfiles/builder.onbuild.Dockerfile) | `gitlab-docs:builder-onbuild` | Base image to build the docs website. It uses `ONBUILD` to perform all steps and depends on `gitlab-docs:bootstrap`.                                                                                                                                                                  |
+| [`nginx.onbuild.Dockerfile`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/dockerfiles/nginx.onbuild.Dockerfile)     | `gitlab-docs:nginx-onbuild`   | Base image to use for building documentation archives. It uses `ONBUILD` to perform all required steps to copy the archive, and relies upon its parent `Dockerfile.builder.onbuild` that is invoked when building single documentation archives (see the `Dockerfile` of each branch) |
+| [`archives.Dockerfile`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/dockerfiles/archives.Dockerfile)               | `gitlab-docs:archives`        | Contains all the versions of the website in one archive. It copies all generated HTML files from every version in one location.                                                                                                                                                       |
 
 ### How to build the images
 
diff --git a/doc/development/documentation/site_architecture/folder_structure.md b/doc/development/documentation/site_architecture/folder_structure.md
index 0e8065d794f..7f29d3fba9e 100644
--- a/doc/development/documentation/site_architecture/folder_structure.md
+++ b/doc/development/documentation/site_architecture/folder_structure.md
@@ -85,7 +85,7 @@ place for it.
 Do not include the same information in multiple places.
 [Link to a single source of truth instead.](../styleguide/index.md#link-instead-of-repeating-text)
 
-For example, if you have code in a repository other than the [primary repositories](index.md#architecture),
+For example, if you have code in a repository other than the [primary repositories](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/architecture.md),
 and documentation in the same repository, you can keep the documentation in that repository.
 
 Then you can either:
diff --git a/doc/development/documentation/site_architecture/global_nav.md b/doc/development/documentation/site_architecture/global_nav.md
index e1e0da03abc..05e697869b9 100644
--- a/doc/development/documentation/site_architecture/global_nav.md
+++ b/doc/development/documentation/site_architecture/global_nav.md
@@ -22,7 +22,7 @@ At the highest level, our global nav is workflow-based. Navigation needs to help
 The levels under each of the higher workflow-based topics are the names of features.
 For example:
 
-**Use GitLab** (_workflow_) **> Build your application** (_workflow_) **> CI/CD** (_feature_) **> Pipelines** (_feature)
+**Use GitLab** (_workflow_) **> Build your application** (_workflow_) **> CI/CD** (_feature_) **> Pipelines** (_feature_)
 
 ## Choose the right words for your navigation entry
 
@@ -39,20 +39,36 @@ as helpful as **Get started with runners**.
 
 ## Add a navigation entry
 
-All topics should be included in the left nav.
-
 To add a topic to the global nav, edit
 [`navigation.yaml`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/content/_data/navigation.yaml)
 and add your item.
 
-All new pages need a navigation item. Without a navigation, the page becomes "orphaned." That
-is:
+Without a navigation entry:
+
+- The navigation closes when the page is opened, and the reader loses their place.
+- The page isn't visible in a group with other pages.
+
+### Pages you don't need to add
+
+Exclude these pages from the global nav:
+
+- Legal notices.
+- Pages in the `architecture/blueprints` directory.
+- Pages in the `user/application_security/dast/checks/` directory.
+
+The following pages should probably be in the global nav, but the technical writers
+do not actively work to add them:
+
+- Pages in the `/development` directory.
+- Pages authored by the support team, which are under the `doc/administration/troubleshooting` directory.
+
+Sometimes pages for deprecated features are not in the global nav, depending on how long ago the feature was deprecated.
 
-- The navigation shuts when the page is opened, and the reader loses their place.
-- The page doesn't belong in a group with other pages.
+All other pages should be in the global nav.
 
-This means the decision to create a new page is a decision to create new navigation item and vice
-versa.
+The technical writing team runs a report to determine which pages are not in the nav.
+For now this report is manual, but [an issue exists](https://gitlab.com/gitlab-org/gitlab-docs/-/issues/1212)
+to automate it.
 
 ### Where to add
 
@@ -283,7 +299,7 @@ The [layout](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/layouts/global_
 is fed by the [data file](#data-file), builds the global nav, and is rendered by the
 [default](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/layouts/default.html) layout.
 
-The global nav contains links from all [four upstream projects](index.md#architecture).
+The global nav contains links from all [four upstream projects](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/architecture.md).
 The [global nav URL](#urls) has a different prefix depending on the documentation file you change.
 
 | Repository                                                     | Link prefix | Final URL                          |
diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md
index af24fbe303b..2864bbe7404 100644
--- a/doc/development/documentation/site_architecture/index.md
+++ b/doc/development/documentation/site_architecture/index.md
@@ -11,247 +11,30 @@ the repository which is used to generate the GitLab documentation website and
 is deployed to <https://docs.gitlab.com>. It uses the [Nanoc](https://nanoc.app/)
 static site generator.
 
-## Architecture
+View the [`gitlab-docs` architecture page](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/architecture.md)
+for more information.
 
-While the source of the documentation content is stored in the repositories for
-each GitLab product, the source that is used to build the documentation
-site _from that content_ is located at <https://gitlab.com/gitlab-org/gitlab-docs>.
+## Documentation in other repositories
 
-The following diagram illustrates the relationship between the repositories
-from where content is sourced, the `gitlab-docs` project, and the published output.
-
-```mermaid
-  graph LR
-    A[gitlab-org/gitlab/doc]
-    B[gitlab-org/gitlab-runner/docs]
-    C[gitlab-org/omnibus-gitlab/doc]
-    D[gitlab-org/charts/gitlab/doc]
-    E[gitlab-org/cloud-native/gitlab-operator/doc]
-    Y[gitlab-org/gitlab-docs]
-    A --> Y
-    B --> Y
-    C --> Y
-    D --> Y
-    E --> Y
-    Y -- Build pipeline --> Z
-    Z[docs.gitlab.com]
-    M[//ee/]
-    N[//runner/]
-    O[//omnibus/]
-    P[//charts/]
-    Q[//operator/]
-    Z --> M
-    Z --> N
-    Z --> O
-    Z --> P
-    Z --> Q
-```
-
-GitLab docs content isn't kept in the `gitlab-docs` repository.
-All documentation files are hosted in the respective repository of each
-product, and all together are pulled to generate the docs website:
-
-- [GitLab](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc)
-- [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/tree/master/doc)
-- [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/-/tree/main/docs)
-- [GitLab Chart](https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/doc)
-- [GitLab Operator](https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/tree/master/doc)
-
-Learn more about [the docs folder structure](folder_structure.md).
-
-### Documentation in other repositories
-
-If you have code and documentation in a repository other than the [primary repositories](#architecture),
+If you have code and documentation in a repository other than the [primary repositories](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/architecture.md),
 you should keep the documentation with the code in that repository.
 
-Then you can either:
+Then you can use one of these approaches:
 
-- [Add the repository to the list of products](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/development.md#add-a-new-product)
-  published at <https://docs.gitlab.com>.
-- [Add an entry in the global navigation](global_nav.md#add-a-navigation-entry) for
-  <https://docs.gitlab.com> that links to the documentation in that repository.
+- Recommended. [Add the repository to the list of products](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/development.md#add-a-new-product)
+  published at <https://docs.gitlab.com>. The source of the documentation pages remains
+  in the external repository, but the resulting pages are indexed and searchable on <https://docs.gitlab.com>.
+- Recommended. [Add an entry in the global navigation](global_nav.md#add-a-navigation-entry) for
+  <https://docs.gitlab.com> that links directly to the documentation in that external repository.
+  The documentation pages are not indexed or searchable on <https://docs.gitlab.com>.
   View [an example](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/fedb6378a3c92274ba3b6031df0d34455594e4cc/content/_data/navigation.yaml#L2944-L2946).
-
-## Assets
-
-To provide an optimized site structure, design, and a search-engine friendly
-website, along with a discoverable documentation, we use a few assets for
-the GitLab Documentation website.
-
-### External libraries
-
-GitLab Docs is built with a combination of external:
-
-- [JavaScript libraries](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/package.json).
-- [Ruby libraries](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/Gemfile).
-
-### SEO
-
-- [Schema.org](https://schema.org/)
-- [Google Analytics](https://marketingplatform.google.com/about/analytics/)
-- [Google Tag Manager](https://developers.google.com/tag-platform/tag-manager)
-
-## Global navigation
-
-Read through [the global navigation documentation](global_nav.md) to understand:
-
-- How the global navigation is built.
-- How to add new navigation items.
-
-<!--
-## Helpers
-
-TBA
--->
-
-## Pipelines
-
-The pipeline in the `gitlab-docs` project:
-
-- Tests changes to the docs site code.
-- Builds the Docker images used in various pipeline jobs.
-- Builds and deploys the docs site itself.
-- Generates the review apps when the `review-docs-deploy` job is triggered.
-
-### Rebuild the docs site Docker images
-
-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 in the [Dockerfiles directory](https://gitlab.com/gitlab-org/gitlab-docs/-/tree/main/dockerfiles).
-
-If you need to rebuild the Docker images immediately (must have maintainer level permissions):
-
-WARNING:
-If you change the Dockerfile configuration and rebuild the images, you can break the main
-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**.
-1. Select **Run pipeline**.
-1. See that a new pipeline is running. The jobs that build the images are in the first
-   stage, `build-images`. You can select the pipeline number to see the larger pipeline
-   graph, or select the first (`build-images`) stage in the mini pipeline graph to
-   expose the jobs that build the images.
-1. Select the **play** (**{play}**) button next to the images you want to rebuild.
-   - Normally, you do not need to rebuild the `image:gitlab-docs-base` image, as it
-     rarely changes. If it does need to be rebuilt, be sure to only run `image:docs-lint`
-     after it is finished rebuilding.
-
-### Deploy the docs site
-
-Every four hours a scheduled pipeline builds and deploys the docs site. The pipeline
-fetches the current docs from the main project's main branch, builds it with Nanoc
-and deploys it to <https://docs.gitlab.com>.
-
-To build and deploy the site immediately (must have the Maintainer role):
-
-1. In [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs), go to **{rocket}** **CI/CD > Schedules**.
-1. For the `Build docs.gitlab.com every 4 hours` scheduled pipeline, select the **play** (**{play}**) button.
-
-Read more about [documentation deployments](deployment_process.md).
-
-## Using YAML data files
-
-The easiest way to achieve something similar to
-[Jekyll's data files](https://jekyllrb.com/docs/datafiles/) in Nanoc is by
-using the [`@items`](https://nanoc.app/doc/reference/variables/#items-and-layouts)
-variable.
-
-The data file must be placed inside the `content/` directory and then it can
-be referenced in an ERB template.
-
-Suppose we have the `content/_data/versions.yaml` file with the content:
-
-```yaml
-versions:
-  - 10.6
-  - 10.5
-  - 10.4
-```
-
-We can then loop over the `versions` array with something like:
-
-```erb
-<% @items['/_data/versions.yaml'][:versions].each do | version | %>
-
-<h3><%= version %></h3>
-
-<% end &>
-```
-
-Note that the data file must have the `yaml` extension (not `yml`) and that
-we reference the array with a symbol (`:versions`).
-
-## Archived documentation banner
-
-A banner is displayed on archived documentation pages with the text `This is archived documentation for
-GitLab. Go to the latest.` when either:
-
-- The version of the documentation displayed is not the first version entry in `online` in
-  `content/_data/versions.yaml`.
-- The documentation was built from the default branch (`main`).
-
-For example, if the `online` entries for `content/_data/versions.yaml` are:
-
-```yaml
-online:
-  - "14.4"
-  - "14.3"
-  - "14.2"
-```
-
-In this case, the archived documentation banner isn't displayed:
-
-- For 14.4, the docs built from the `14.4` branch. The branch name is the first entry in `online`.
-- For 14.5-pre, the docs built from the default project branch (`main`).
-
-The archived documentation banner is displayed:
-
-- For 14.3.
-- For 14.2.
-- For any other version.
-
-## 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 front matter. This method guarantees that
-your changes take effect by clearing the cache of previous files.
-
-Always use Nanoc's way of including those files, do not hardcode them in the
-layouts. For example use:
-
-```erb
-<script async type="application/javascript" src="<%= @items['/assets/javascripts/badges.*'].path %>"></script>
-
-<link rel="stylesheet" href="<%= @items['/assets/stylesheets/toc.*'].path %>">
-```
-
-The links pointing to the files should be similar to:
-
-```erb
-<%= @items['/path/to/assets/file.*'].path %>
-```
-
-Nanoc then builds and renders those links correctly according with what's
-defined in [`Rules`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/Rules).
-
-## Linking to source files
-
-A helper called [`edit_on_gitlab`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/lib/helpers/edit_on_gitlab.rb) can be used
-to link to a page's source file. We can link to both the simple editor and the
-web IDE. Here's how you can use it in a Nanoc layout:
-
-- Default editor: `<a href="<%= edit_on_gitlab(@item, editor: :simple) %>">Simple editor</a>`
-- Web IDE: `<a href="<%= edit_on_gitlab(@item, editor: :webide) %>">Web IDE</a>`
-
-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/)
-for its search function.
-
-Learn more in <https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/docsearch.md>.
+- Create a landing page for the product in the `gitlab` repository, and add the landing page
+  [to the global navigation](global_nav.md#add-a-navigation-entry), but keep the rest
+  of the documentation in the external repository. The landing page is indexed and
+  searchable on <https://docs.gitlab.com>, but the rest of the documentation is not.
+  For example, the [GitLab Workflow extension for VS Code](../../../user/project/repository/vscode.md).
+  We do not encourage the use of [pages with lists of links](../structure.md#topics-and-resources-pages),
+  so only use this option if the recommended options are not feasible.
 
 ## Monthly release process (versions)
 
@@ -260,5 +43,5 @@ For more information, read about the [monthly release process](https://gitlab.co
 
 ## Review Apps for documentation merge requests
 
-If you are contributing to GitLab docs read how to [create a Review App with each
-merge request](../index.md#previewing-the-changes-live).
+If you are contributing to GitLab docs read how to
+[create a Review App with each merge request](../index.md#previewing-the-changes-live).
diff --git a/doc/development/documentation/structure.md b/doc/development/documentation/structure.md
index a02046d4466..a5d1290a17a 100644
--- a/doc/development/documentation/structure.md
+++ b/doc/development/documentation/structure.md
@@ -148,35 +148,60 @@ Avoid these heading titles:
 
 ## Troubleshooting
 
-Troubleshooting can be one of two categories:
+Troubleshooting topics should be the last topics on a page.
 
-- **Troubleshooting task.** This information is written the same way as a [standard task](#task).
+Troubleshooting can be one of three categories:
+
+- **An introductory topic.** This topic introduces the troubleshooting section of a page.
+  For example:
+
+  ```markdown
+  ## Troubleshooting
+
+  When working with <x feature>, you might encounter the following issues.
+  ```
+
+- **Troubleshooting task.** The title should be similar to a [standard task](#task).
   For example, "Run debug tools" or "Verify syntax."
-- **Troubleshooting reference.** This information has a specific format.
 
-Troubleshooting reference information should be in this format:
+- **Troubleshooting reference.** This information includes the error message. For example:
 
-```markdown
-# Title (the error message or a description of it)
+  ```markdown
+  ### The error message or a description of it
 
-You might get an error that states <error message>.
+  You might get an error that states <error message>.
 
-This issue occurs when...
+  This issue occurs when...
 
-The workaround is...
-```
+  The workaround is...
+  ```
 
-If multiple causes or workarounds exist, consider putting them into a table format.
+  If multiple causes or workarounds exist, consider putting them into a table format.
+  If you use the exact error message, surround it in backticks so it's styled as code.
+
+If a page has more than five troubleshooting topics, put the content on a separate page that has troubleshooting information exclusively. Name the page `Troubleshooting <featurename>`.
 
 ### Troubleshooting headings
 
-For the heading:
+For the heading of a **Troubleshooting reference** topic:
 
 - Consider including at least a partial error message.
 - Use fewer than 70 characters.
 
 If you do not put the full error in the title, include it in the body text.
 
+### Related topics
+
+If inline links are not sufficient, you can create a topic called **Related topics**
+and include an unordered list of related topics. This topic should be above the Troubleshooting section.
+
+```markdown
+# Related topics
+
+- [Configure your pipeline](link-to-topic)
+- [Trigger a pipeline manually](link-to-topic)
+```
+
 ## General heading text guidelines
 
 In general, for heading text:
@@ -272,18 +297,6 @@ If you need to add more than one task,
 consider using subsections for each distinct task.
 ```
 
-### Related topics
-
-If inline links are not sufficient, you can create a topic called **Related topics**
-and include an unordered list of related topics. This topic should be above the Troubleshooting section.
-
-```markdown
-# Related topics
-
-- [Configure your pipeline](link-to-topic)
-- [Trigger a pipeline manually](link-to-topic)
-```
-
 ### Topics and resources pages
 
 This page has a list of links that point to important sections
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index 1af0cb72055..709e6b2d0d9 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -150,6 +150,8 @@ the page is rendered to HTML. There can be only **one** level 1 heading per page
 
 - For each subsection, increment the heading level. In other words, increment the number of `#` characters
   in front of the heading.
+- Avoid headings greater than `H5` (`#####`). If you need more than five heading levels, move the topics to a new page instead.
+  Headings greater than `H5` do not display in the right sidebar navigation.
 - Do not skip a level. For example: `##` > `####`.
 - Leave one blank line before and after the heading.
 
@@ -162,6 +164,13 @@ Also, do not use links as part of heading text.
 
 See also [heading guidelines for specific topic types](../structure.md).
 
+### Backticks in Markdown
+
+Use backticks for:
+
+- [Code blocks](#code-blocks).
+- Error messages.
+
 ### Markdown Rules
 
 GitLab ensures that the Markdown used across all documentation is consistent, as
@@ -722,10 +731,12 @@ We include guidance for links in these categories:
 
 - Use inline link Markdown markup `[Text](https://example.com)`.
   It's easier to read, review, and maintain. Do not use `[Text][identifier]` reference-style links.
-
 - Use meaningful anchor text.
   For example, instead of writing something like `Read more about merge requests [here](LINK)`,
   write `Read more about [merge requests](LINK)`.
+- Put the entire link on a single line. Some of our [linters](../testing.md) do not
+  validate links when split over multiple lines, and incorrect or broken links could
+  slip through.
 
 ### Links to internal documentation
 
@@ -787,45 +798,15 @@ 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're
-linking to an [**authoritative** source](#authoritative-sources). For example,
-if you're describing a feature in Microsoft's Active Directory, include a link
-to official Microsoft documentation.
-
-### Authoritative sources
-
-When citing external information, use sources that are written by the people who
-created the item or product in question. These sources are the most likely to be
-accurate and remain up to date.
-
-Examples of authoritative sources include:
-
-- Specifications, such as a [Request for Comments](https://www.ietf.org/standards/rfcs/)
-  document from the Internet Engineering Task Force.
-- Official documentation for a product. For example, if you're setting up an
-  interface with the Google OAuth 2 authorization server, include a link to
-  Google's documentation.
-- Official documentation for a project. For example, if you're citing NodeJS
-  functionality, refer directly to [NodeJS documentation](https://nodejs.org/en/docs/).
-- Books from an authoritative publisher.
+When possible, avoid links to external documentation. These links can easily become outdated, and are difficult to maintain.
 
-Examples of sources to avoid include:
+- [They lead to link rot](https://en.wikipedia.org/wiki/Link_rot).
+- [They create issues with maintenance](https://gitlab.com/gitlab-org/gitlab/-/issues/368300).
 
-- Personal blog posts.
-- Wikipedia.
-- Non-trustworthy articles.
-- Discussions on forums such as Stack Overflow.
-- Documentation from a company that describes another company's product.
+Sometimes links are required. They might clarify troubleshooting steps or help prevent duplication of content.
+Sometimes they are more precise and will be maintained more actively.
 
-While many of these sources to avoid can help you learn skills and or features,
-they can become obsolete quickly. Nobody is obliged to maintain any of these
-sites. Therefore, we should avoid using them as reference literature.
-
-NOTE:
-Non-authoritative sources are acceptable only if there is no equivalent
-authoritative source. Even then, focus on non-authoritative sources that are
-extensively cited or peer-reviewed.
+For each external link you add, weigh the customer benefit with the maintenance difficulties.
 
 ### Links requiring permissions
 
@@ -950,6 +931,16 @@ For example:
 1. Optional. Enter a description for the job.
 ```
 
+### Recommended steps
+
+If a step is recommended, start the step with the word `Recommended` followed by a period.
+
+For example:
+
+```markdown
+1. Recommended. Enter a description for the job.
+```
+
 ### Documenting multiple fields at once
 
 If the UI text sufficiently explains the fields in a section, do not include a task step for every field.
@@ -1106,6 +1097,36 @@ include a visual representation to help readers understand it, you can:
   an area of the screen.
 - Create a short video of the interaction and link to it.
 
+## Emojis
+
+Don't use the Markdown emoji format, for example `:smile:`, for any purpose. Use
+[GitLab SVG icons](#gitlab-svg-icons) instead.
+
+Use of emoji in Markdown requires GitLab Flavored Markdown, which is not supported by Kramdown,
+the Markdown rendering engine used for GitLab documentation.
+
+## GitLab SVG icons
+
+> [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. For example, `**{tanuki}**` renders as: **{tanuki}**.
+
+In most cases, you should avoid using the icons in text.
+However, you can use an icon when hover text is the only
+available way to describe a UI element. For example, **Delete** or **Edit** buttons
+often have hover text only.
+
+When you do use an icon, start with the hover text and follow it with the SVG reference in parentheses.
+
+- Avoid: `Select **{pencil}** **Edit**.` This generates as: Select **{pencil}** **Edit**.
+- Use instead: `Select **Edit** (**{pencil}**).` This generates as: Select **Edit** (**{pencil}**).
+
+Do not use words to describe the icon:
+
+- Avoid: `Select **Erase job log** (the trash icon).`
+- Use instead: `Select **Erase job log** (**{remove}**).` This generates as: Select **Erase job log** (**{remove}**).
+
 ## Videos
 
 Adding GitLab YouTube video tutorials to the documentation is highly
@@ -1187,28 +1208,6 @@ different mobile devices.
 `/help`, because the GitLab Markdown processor doesn't support iframes. It's
 hidden on the documentation site, but is displayed by `/help`.
 
-## GitLab SVG icons
-
-> [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. For example, `**{tanuki}**` renders as: **{tanuki}**.
-
-In most cases, you should avoid using the icons in text.
-However, you can use an icon when hover text is the only
-available way to describe a UI element. For example, **Delete** or **Edit** buttons
-often have hover text only.
-
-When you do use an icon, start with the hover text and follow it with the SVG reference in parentheses.
-
-- Avoid: `Select **{pencil}** **Edit**.` This generates as: Select **{pencil}** **Edit**.
-- Use instead: `Select **Edit** (**{pencil}**).` This generates as: Select **Edit** (**{pencil}**).
-
-Do not use words to describe the icon:
-
-- Avoid: `Select **Erase job log** (the trash icon).`
-- Use instead: `Select **Erase job log** (**{remove}**).` This generates as: Select **Erase job log** (**{remove}**).
-
 ## Alert boxes
 
 Use alert boxes to call attention to information. Use them sparingly, and never have an alert box immediately follow another alert box.
diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md
index c753c39b727..1976caefc8e 100644
--- a/doc/development/documentation/styleguide/word_list.md
+++ b/doc/development/documentation/styleguide/word_list.md
@@ -239,6 +239,13 @@ Use **CI/CD minutes** instead of **CI minutes**, **pipeline minutes**, **pipelin
 Do not use **click**. Instead, use **select** with buttons, links, menu items, and lists.
 **Select** applies to more devices, while **click** is more specific to a mouse.
 
+## cloud native
+
+When you're talking about using a Kubernetes cluster to host GitLab, you're talking about a **cloud-native version of GitLab**.
+This version is different than the larger, more monolithic **Omnibus package** that is used to deploy GitLab.
+
+You can also use **cloud-native GitLab** for short. It should be hyphenated and lowercase.
+
 ## collapse
 
 Use **collapse** instead of **close** when you are talking about expanding or collapsing a section in the UI.
@@ -434,6 +441,17 @@ Do not make **GitLab** possessive (GitLab's). This guidance follows [GitLab Trad
 
 **GitLab.com** refers to the GitLab instance managed by GitLab itself.
 
+## GitLab Helm chart, GitLab chart
+
+To deploy a cloud-native version of GitLab, use:
+
+- The GitLab Helm chart (long version)
+- The GitLab chart (short version)
+
+Do not use **the `gitlab` chart**, **the GitLab Chart**, or **the cloud-native chart**.
+
+You use the **GitLab Helm chart** to deploy **cloud-native GitLab** in a Kubernetes cluster.
+
 ## GitLab Flavored Markdown
 
 When possible, spell out [**GitLab Flavored Markdown**](../../../user/markdown.md).
@@ -1127,7 +1145,7 @@ in present tense, active voice.
 ## you, your, yours
 
 Use **you**, **your**, and **yours** instead of [**the user** and **the user's**](#user-users).
-Documentation should be from the [point of view](https://design.gitlab.com/content/voice-tone#point-of-view) of the reader.
+Documentation should be from the [point of view](https://design.gitlab.com/content/voice-tone/#point-of-view) of the reader.
 
 Use:
 
diff --git a/doc/development/documentation/testing.md b/doc/development/documentation/testing.md
index d55cbe28d9b..428a57a11fb 100644
--- a/doc/development/documentation/testing.md
+++ b/doc/development/documentation/testing.md
@@ -81,6 +81,36 @@ This requires you to either:
 
 ### Documentation link tests
 
+Merge requests containing changes to Markdown (`.md`) files run a `docs-lint links`
+job, which runs two types of link checks. In both cases, links with destinations
+that begin with `http` or `https` are considered external links, and skipped:
+
+- `bundle exec nanoc check internal_links`: Tests links to internal pages.
+- `bundle exec nanoc check internal_anchors`: Tests links to subheadings (anchors) on internal pages.
+
+Failures from these tests are displayed at the end of the test results in the **Issues found!** area.
+For example, failures in the `internal_anchors` test follow this format:
+
+```plaintext
+[ ERROR ] internal_anchors - Broken anchor detected!
+  - source file `/tmp/gitlab-docs/public/ee/user/application_security/api_fuzzing/index.html`
+  - destination `/tmp/gitlab-docs/public/ee/development/code_review.html`
+  - link `../../../development/code_review.html#review-response-slo`
+  - anchor `#review-response-slo`
+```
+
+- **Source file**: The full path to the file containing the error. To find the
+  file in the `gitlab` repository, replace `/tmp/gitlab-docs/public/ee` with `doc`, and `.html` with `.md`.
+- **Destination**: The full path to the file not found by the test. To find the
+  file in the `gitlab` repository, replace `/tmp/gitlab-docs/public/ee` with `doc`, and `.html` with `.md`.
+- **Link**: The actual link the script attempted to find.
+- **Anchor**: If present, the subheading (anchor) the script attempted to find.
+
+Check for multiple instances of the same broken link on each page reporting an error.
+Even if a specific broken link appears multiple times on a page, the test reports it only once.
+
+#### Run document link tests locally
+
 To execute documentation link tests locally:
 
 1. Navigate to the [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) directory.
@@ -219,12 +249,12 @@ You can use markdownlint:
 
 ### Vale
 
-[Vale](https://docs.errata.ai/vale/about/) is a grammar, style, and word usage linter for the
+[Vale](https://vale.sh/) is a grammar, style, and word usage linter for the
 English language. Vale's configuration is stored in the
 [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.vale.ini) file located in the root
 directory of projects.
 
-Vale supports creating [custom tests](https://docs.errata.ai/vale/styles) that extend any of
+Vale supports creating [custom tests](https://vale.sh/docs/topics/styles/) that extend any of
 several types of checks, which we store in the `.linting/vale/styles/gitlab` directory in the
 documentation directory of projects.
 
@@ -241,7 +271,7 @@ This configuration is also used in build pipelines, where
 
 You can use Vale:
 
-- [On the command line](https://docs.errata.ai/vale/cli).
+- [On the command line](https://vale.sh/docs/vale-cli/structure/).
 - [In a code editor](#configure-editors).
 - [In a Git hook](#configure-pre-push-hooks). Vale only reports errors in the Git hook (the same
   configuration as the CI/CD pipelines), and does not report suggestions or warnings.
@@ -250,7 +280,8 @@ You can use Vale:
 
 Vale returns three types of results:
 
-- **Error** - For branding and trademark issues, and words or phrases with ambiguous meanings.
+- **Error** - For branding guidelines, trademark guidelines, and anything that causes content on
+  the docs site to render incorrectly.
 - **Warning** - For Technical Writing team style preferences.
 - **Suggestion** - For basic technical writing tenets and best practices.
 
@@ -304,7 +335,30 @@ For example, a page that scores `12` before a set of changes, and `9` after, ind
 general complexity level of the page.
 
 The readability score is calculated based on the number of words per sentence, and the number
-of syllables per word. For more information, see [the Vale documentation](https://docs.errata.ai/vale/styles#metric).
+of syllables per word. For more information, see [the Vale documentation](https://vale.sh/docs/topics/styles/#metric).
+
+#### When to add a new Vale rule
+
+It's tempting to add a Vale rule for every style guide rule. However, we should be
+mindful of the effort to create and enforce a Vale rule, and the noise it creates.
+
+In general, follow these guidelines:
+
+- If you add an [error-level Vale rule](#vale-result-types), you must fix
+  the existing occurrences of the issue in the documentation before you can add the rule.
+
+  If there are too many issues to fix in a single merge request, add the rule at a
+  `warning` level. Then, fix the existing issues in follow-up merge requests.
+  When the issues are fixed, promote the rule to an `error`.
+
+- If you add a warning-level or suggestion-level rule, consider:
+
+  - How many more warnings or suggestions it creates in the Vale output. If the
+    number of additional warnings is significant, the rule might be too broad.
+
+  - How often an author might ignore it because it's acceptable in the context.
+    If the rule is too subjective, it cannot be adequately enforced and creates
+    unnecessary additional warnings.
 
 ### Install linters
 
@@ -399,8 +453,6 @@ To configure Vale in your editor, install one of the following as appropriate:
   In this setup the `markdownlint` checker is set as a "next" checker from the defined `vale` checker.
   Enabling this custom Vale checker provides error linting from both Vale and markdownlint.
 
-We don't use [Vale Server](https://docs.errata.ai/vale-server/install).
-
 ### Configure pre-push hooks
 
 Git [pre-push hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) allow Git users to:
@@ -479,7 +531,7 @@ document:
 Whenever possible, exclude only the problematic rule and lines.
 
 For more information, see
-[Vale's documentation](https://docs.errata.ai/vale/scoping#markup-based-configuration).
+[Vale's documentation](https://vale.sh/docs/topics/scoping/).
 
 ### Disable markdownlint tests
 
diff --git a/doc/development/documentation/versions.md b/doc/development/documentation/versions.md
index 067c37d30aa..3679c731a77 100644
--- a/doc/development/documentation/versions.md
+++ b/doc/development/documentation/versions.md
@@ -182,7 +182,7 @@ GitLab supports the current major version and two previous major versions.
 For example, if 15.0 is the current major version, all major and minor releases of
 GitLab 15.0, 14.0, and 13.0 are supported.
 
-[View the list of supported versions](https://about.gitlab.com/support/statement-of-support.html#version-support).
+[View the list of supported versions](https://about.gitlab.com/support/statement-of-support/#version-support).
 
 If you see version history items or inline text that refers to unsupported versions, you can remove it.
 
@@ -198,8 +198,8 @@ We cannot guarantee future feature work, and promises
 like these can raise legal issues. Instead, say that an issue exists.
 For example:
 
-- Support for improvements is tracked `[in this issue](LINK)`.
-- You cannot do this thing, but `[an issue exists](LINK)` to change this behavior.
+- Support for improvements is proposed in issue `[issue-number](LINK-TO-ISSUE)`.
+- You cannot do this thing, but issue `[issue-number](LINK-TO-ISSUE)` proposes to change this behavior.
 
 You can say that we plan to remove a feature.