Add latest changes from gitlab-org/gitlab@master

11 files changed, 219 insertions, 138 deletions

diff --git a/doc/api/index.md b/doc/api/index.md
index e4b7cc56aab..76d31c35b96 100644
--- a/doc/api/index.md
+++ b/doc/api/index.md
@@ -245,6 +245,68 @@ your [runners](../ci/runners/README.md) to be secure. Avoid:
 If you have an insecure GitLab Runner configuration, you increase the risk that someone
 tries to steal tokens from other jobs.
 
+#### GitLab CI/CD job token scope
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/328553) in GitLab 14.1.
+
+- [Deployed behind a feature flag](../user/feature_flags.md), disabled by default.
+- Disabled on GitLab.com.
+- Not recommended for production use.
+- To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-ci-job-token-scope). **(FREE SELF)**
+
+This in-development feature might not be available for your use. There can be
+[risks when enabling features still in development](../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+Refer to this feature's version history for more details.
+
+CI job token can access only projects that are defined in its scope.
+You can configure the scope via project settings.
+
+The CI job token scope consists in a allowlist of projects that are authorized by maintainers to be
+accessible via a CI job token. By default a scope only contains the same project where the token
+comes from. Other projects can be added and removed by maintainers.
+
+You can configure the scope via project settings.
+
+Since GitLab 14.1 this setting is enabled by default for new projects. Existing projects are
+recommended to enable this feature and configure which projects are authorized to be accessed
+by a job token.
+
+The CI job token scope limits the risks that a leaked token is used to access private data that
+the user associated to the job can access to.
+
+When the job token scope feature is enabled in the project settings, only the projects in scope
+will be allowed to be accessed by a job token. If the job token scope feature is disabled, any
+projects can be accessed, as long as the user associated to the job has permissions.
+
+For example. If a project `A` has a running job with a `CI_JOB_TOKEN`, its scope is defined by
+project `A`. If the job wants to use the `CI_JOB_TOKEN` to access data from project `B` or
+trigger some actions in that project, then project `B` must be in the job token scope for `A`.
+
+A job token might give extra permissions that aren't necessary to access specific resources.
+There is [a proposal](https://gitlab.com/groups/gitlab-org/-/epics/3559) to redesign the feature
+for more strategic control of the access permissions.
+
+<!-- Add this at the end of the file -->
+
+#### Enable or disable CI Job Token Scope **(FREE SELF)**
+
+This 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](../administration/feature_flags.md)
+can enable it.
+
+To enable it:
+
+```ruby
+Feature.enable(:ci_scoped_job_token)
+```
+
+To disable it:
+
+```ruby
+Feature.disable(:ci_scoped_job_token)
+```
+
 ### Impersonation tokens
 
 Impersonation tokens are a type of [personal access token](../user/profile/personal_access_tokens.md).
diff --git a/doc/development/changelog.md b/doc/development/changelog.md
index c9d2d820c54..c96fe2c18c1 100644
--- a/doc/development/changelog.md
+++ b/doc/development/changelog.md
@@ -98,6 +98,7 @@ EE: true
   database records created during Cycle Analytics model spec."
 - _Any_ contribution from a community member, no matter how small, **may** have
   a changelog entry regardless of these guidelines if the contributor wants one.
+- [Removing](feature_flags/#changelog) a feature flag, when the new code is retained.
 
 ## Writing good changelog entries
 
diff --git a/doc/development/documentation/structure.md b/doc/development/documentation/structure.md
index 9449fd52839..4fe3458b909 100644
--- a/doc/development/documentation/structure.md
+++ b/doc/development/documentation/structure.md
@@ -7,37 +7,40 @@ description: What to include in GitLab documentation pages.
 
 # Documentation topic types
 
-At GitLab, we have not traditionally used topic types. However, we are starting to
-move in this direction, and we now use four topic types:
+At GitLab, we have not traditionally used types for our content. However, we are starting to
+move in this direction, and we now use four primary topic types:
 
 - [Concept](#concept)
 - [Task](#task)
 - [Reference](#reference)
 - [Troubleshooting](#troubleshooting)
 
-Each page contains multiple topic types. For example,
-a page with the title `Pipelines`, which is generated from a file called `index.md`,
-can include a concept and multiple task and reference topics.
+In general, each page in our docset contains multiple topics. (Each heading indicates a new topic.)
+Each topic on a page should be a specific topic type. For example,
+a page with the title `Pipelines` can include topics that are concepts and tasks.
+
+A page might also contain only one type of information. These pages are generally one of our
+[other content types](#other-types-of-content).
 
 ## Concept
 
-A concept topic introduces a single feature or concept.
+A concept introduces a single feature or concept.
 
 A concept should answer the questions:
 
 - What is this?
 - Why would I use it?
 
-Think of everything someone might want to know if they've never heard of this topic before.
+Think of everything someone might want to know if they've never heard of this concept before.
 
 Don't tell them **how** to do this thing. Tell them **what it is**.
 
-If you start describing another topic, start a new concept and link to it.
+If you start describing another concept, start a new concept and link to it.
 
-Also, do not use "Overview" or "Introduction" for the topic title. Instead,
+Also, do not use **Overview** or **Introduction** for the title. Instead,
 use a noun or phrase that someone would search for.
 
-Concept topics should be in this format:
+Concepts should be in this format:
 
 ```markdown
 # Title (a noun, like "Widgets")
@@ -47,14 +50,14 @@ A paragraph that explains what this thing is.
 Another paragraph that explains what this thing is.
 
 Remember, if you start to describe about another concept, stop yourself.
-Each concept topic should be about one concept only.
+Each concept should be about one concept only.
 ```
 
 ## Task
 
-A task topic gives instructions for how to complete a procedure.
+A task gives instructions for how to complete a procedure.
 
-Task topics should be in this format:
+Tasks should be in this format:
 
 ```markdown
 # Title (starts with an active verb, like "Create a widget" or "Delete a widget")
@@ -89,20 +92,21 @@ Prerequisites:
 
 To create an issue:
 
-1. Go to **Issues > List**.
-1. In the top right, select **New issue**.
-1. Complete the fields. (If you have a reference topic that lists each field, link to it here.)
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Issues > List**.
+1. In the top right corner, select **New issue**.
+1. Complete the fields. (If you have reference content that lists each field, link to it here.)
 1. Select **Create issue**.
 
 The issue is created. You can view it by going to **Issues > List**.
 ```
 
-If you have several tasks on a page that share prerequisites, you can make a
-reference topic with the title **Prerequisites**, and link to it.
+If you have several tasks on a page that share prerequisites, you can use the title
+**Prerequisites**, and link to it.
 
 ## Reference
 
-A reference topic provides information in an easily-scannable format,
+Reference information should be in an easily-scannable format,
 like a table or list. It's similar to a dictionary or encyclopedia entry.
 
 ```markdown
@@ -115,18 +119,18 @@ Introductory sentence.
 | **Name** | Descriptive sentence about the setting. |
 ```
 
-If a feature or concept has its own prerequisites, you can use the reference
-topic type to create a **Prerequisites** header for the information.
+If a feature or concept has its own prerequisites, you can use reference
+content to create a **Prerequisites** header for the information.
 
 ## Troubleshooting
 
-Troubleshooting topics can be one of two categories:
+Troubleshooting can be one of two categories:
 
-- **Troubleshooting task.** This topic is written the same as a [standard task topic](#task).
+- **Troubleshooting task.** This information is written the same way as a [standard task](#task).
   For example, "Run debug tools" or "Verify syntax."
-- **Troubleshooting reference.** This topic has a specific format.
+- **Troubleshooting reference.** This information has a specific format.
 
-Troubleshooting reference topics should be in this format:
+Troubleshooting reference information should be in this format:
 
 ```markdown
 # Title (the error message or a description of it)
@@ -138,104 +142,24 @@ This issue occurs when...
 The workaround is...
 ```
 
-For the topic title:
+For the heading:
 
-- Consider including at least a partial error message in the title.
+- Consider including at least a partial error message.
 - Use fewer than 70 characters.
 
-Remember to include the complete error message in the topics content if it is
-not complete in the title.
-
-## Other information on a topic
-
-Topics include other information.
-
-For example:
-
-- Each topic must have a [tier badge](styleguide/index.md#product-tier-badges).
-- New topics must have information about the
-  [GitLab version where the feature was introduced](styleguide/index.md#where-to-put-version-text).
-
-### Help and feedback section
-
-This section ([introduced](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/319) in GitLab 11.4)
-is displayed at the end of each document and can be omitted by adding a key into
-the front matter:
-
-```yaml
----
-feedback: false
----
-```
-
-The default is to leave it there. If you want to omit it from a document, you
-must check with a technical writer before doing so.
-
-#### Disqus
-
-We also have integrated the docs site with Disqus (introduced by
-[!151](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/151)),
-allowing our users to post comments.
-
-To omit only the comments from the feedback section, use the following key in
-the front matter:
-
-```yaml
----
-comments: false
----
-```
-
-We're hiding comments only in main index pages, such as [the main documentation index](../../index.md),
-since its content is too broad to comment on. Before omitting Disqus, you must
-check with a technical writer.
-
-Note that after adding `feedback: false` to the front matter, it will omit
-Disqus, therefore, don't add both keys to the same document.
-
-The click events in the feedback section are tracked with Google Tag Manager.
-The conversions can be viewed on Google Analytics by navigating to
-**Behavior > Events > Top events > docs**.
-
-### Guidelines for good practices
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36576/) in GitLab 13.2 as GitLab Development documentation.
-
-*Good practice* examples demonstrate encouraged ways of writing code while
-comparing with examples of practices to avoid. These examples are labeled as
-*Bad* or *Good*. In GitLab development guidelines, when presenting the cases,
-it's recommended to follow a *first-bad-then-good* strategy. First demonstrate
-the *Bad* practice (how things *could* be done, which is often still working
-code), and then how things *should* be done better, using a *Good* example. This
-is typically an improved example of the same code.
-
-Consider the following guidelines when offering examples:
-
-- First, offer the *Bad* example, and then the *Good* one.
-- When only one bad case and one good case is given, use the same code block.
-- When more than one bad case or one good case is offered, use separated code
-  blocks for each. With many examples being presented, a clear separation helps
-  the reader to go directly to the good part. Consider offering an explanation
-  (for example, a comment, or a link to a resource) on why something is bad
-  practice.
-- Better and best cases can be considered part of the good case(s) code block.
-  In the same code block, precede each with comments: `# Better` and `# Best`.
-
-Although the bad-then-good approach is acceptable for the GitLab development
-guidelines, do not use it for user documentation. For user documentation, use
-*Do* and *Don't*. For examples, see the [Pajamas Design System](https://design.gitlab.com/content/punctuation/).
+If you do not put the full error in the title, include it in the body text.
 
 ## Other types of content
 
 There are other types of content in the GitLab documentation that don't
-classify as one of the four [topic types](#documentation-topic-types).
+classify as one of the four primary [topic types](#documentation-topic-types).
 These include:
 
 - [Tutorials](#tutorials)
 - [Get started pages](#get-started)
 - [Topics and resources pages](#topics-and-resources-pages)
 
-In most cases, these content types are on their own standalone page.
+In most cases, these pages are standalone.
 
 ### Tutorials
 
@@ -315,10 +239,78 @@ or you have to create one, use this format:
 
 Brief sentence to describe the feature.
 
-The following topics and resources can help you understand and work with this feature:
+Refer to these resources for more information about <this feature>:
 
 - Link 1
 - Link 2
 - Link 3
+```
+
+## Help and feedback section
+
+This section ([introduced](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/319) in GitLab 11.4)
+is displayed at the end of each document and can be omitted by adding a key into
+the front matter:
+
+```yaml
+---
+feedback: false
+---
+```
+
+The default is to leave it there. If you want to omit it from a document, you
+must check with a technical writer before doing so.
+
+### Disqus
+
+We also have integrated the docs site with Disqus (introduced by
+[!151](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/151)),
+allowing our users to post comments.
+
+To omit only the comments from the feedback section, use the following key in
+the front matter:
 
+```yaml
+---
+comments: false
+---
 ```
+
+We're hiding comments only in main index pages, such as [the main documentation index](../../index.md),
+since its content is too broad to comment on. Before omitting Disqus, you must
+check with a technical writer.
+
+Note that after adding `feedback: false` to the front matter, it will omit
+Disqus, therefore, don't add both keys to the same document.
+
+The click events in the feedback section are tracked with Google Tag Manager.
+The conversions can be viewed on Google Analytics by navigating to
+**Behavior > Events > Top events > docs**.
+
+## Guidelines for good practices
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36576/) in GitLab 13.2 as GitLab Development documentation.
+
+*Good practice* examples demonstrate encouraged ways of writing code while
+comparing with examples of practices to avoid. These examples are labeled as
+*Bad* or *Good*. In GitLab development guidelines, when presenting the cases,
+it's recommended to follow a *first-bad-then-good* strategy. First demonstrate
+the *Bad* practice (how things *could* be done, which is often still working
+code), and then how things *should* be done better, using a *Good* example. This
+is typically an improved example of the same code.
+
+Consider the following guidelines when offering examples:
+
+- First, offer the *Bad* example, and then the *Good* one.
+- When only one bad case and one good case is given, use the same code block.
+- When more than one bad case or one good case is offered, use separated code
+  blocks for each. With many examples being presented, a clear separation helps
+  the reader to go directly to the good part. Consider offering an explanation
+  (for example, a comment, or a link to a resource) on why something is bad
+  practice.
+- Better and best cases can be considered part of the good case(s) code block.
+  In the same code block, precede each with comments: `# Better` and `# Best`.
+
+Although the bad-then-good approach is acceptable for the GitLab development
+guidelines, do not use it for user documentation. For user documentation, use
+*Do* and *Don't*. For examples, see the [Pajamas Design System](https://design.gitlab.com/content/punctuation/).
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index ac5a7268c54..397153a0abb 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -21,6 +21,10 @@ All newly-introduced feature flags should be [disabled by default](https://about
 NOTE:
 This document is the subject of continued work as part of an epic to [improve internal usage of Feature Flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic.
 
+## When to use feature flags
+
+Moved to the ["When to use feature flags"](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) section in the handbook.
+
 ## Feature flags in GitLab development
 
 The following highlights should be considered when deciding if feature flags
diff --git a/doc/development/index.md b/doc/development/index.md
index bc996fdff21..e26dd6e105c 100644
--- a/doc/development/index.md
+++ b/doc/development/index.md
@@ -143,6 +143,13 @@ In these cases, use the following workflow:
    for final content review and merge. The Technical Writer may ask for
    additional approvals as previously suggested before merging the MR.
 
+### Reviewer values
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57293) in GitLab 14.1.
+
+As a reviewer or as a reviewee, make sure to familiarize yourself with
+the [reviewer values](https://about.gitlab.com/handbook/engineering/workflow/reviewer-values/) we strive for at GitLab.
+
 ## UX and Frontend guides
 
 - [GitLab Design System](https://design.gitlab.com/), for building GitLab with
diff --git a/doc/development/multi_version_compatibility.md b/doc/development/multi_version_compatibility.md
index acdf8194cb1..8e49afda579 100644
--- a/doc/development/multi_version_compatibility.md
+++ b/doc/development/multi_version_compatibility.md
@@ -43,6 +43,10 @@ Is it ok if all GitLab nodes have been updated, but the post-deployment migratio
 
 Is it ok if all nodes have been updated, and then the post-deployment migrations get executed a couple days later, and then the background migrations take a week to finish?
 
+### When upgrading a dependency like Rails
+
+Is it ok that some nodes have the new Rails version, but some nodes have the old Rails version?
+
 ## A walkthrough of an update
 
 Backwards compatibility problems during updates are often very subtle. This is why it is worth familiarizing yourself with [update instructions](../update/index.md), [reference architectures](../administration/reference_architectures/index.md), and [GitLab.com's architecture](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/). But to illustrate how these problems arise, take a look at this example of a simple update.
@@ -102,6 +106,13 @@ Yes! We have specific instructions for [zero-downtime updates](../update/index.m
 
 ## I've identified a potential backwards compatibility problem, what can I do about it?
 
+### Coordinate
+
+For major or minor version updates of Rails or Puma:
+
+- Engage the Quality team to thoroughly test the MR.
+- Notify the `@gitlab-org/release/managers` on the MR prior to merging.
+
 ### Feature flags
 
 One way to handle this is to use a feature flag that is disabled by
diff --git a/doc/development/sql.md b/doc/development/sql.md
index a98645cfcae..ddca88cb9bb 100644
--- a/doc/development/sql.md
+++ b/doc/development/sql.md
@@ -70,7 +70,7 @@ WHERE title ILIKE '%Draft:%';
 Because the value for `ILIKE` starts with a wildcard the database is not able to
 use an index as it doesn't know where to start scanning the indexes.
 
-Luckily, PostgreSQL _does_ provide a solution: trigram GIN indexes. These
+Luckily, PostgreSQL _does_ provide a solution: trigram Generalized Inverted Index (GIN) indexes. These
 indexes can be created as follows:
 
 ```sql
@@ -261,9 +261,9 @@ from `ActiveRecord::Base`.
 
 ## Use UNIONs
 
-UNIONs aren't very commonly used in most Rails applications but they're very
-powerful and useful. In most applications queries tend to use a lot of JOINs to
-get related data or data based on certain criteria, but JOIN performance can
+`UNION`s aren't very commonly used in most Rails applications but they're very
+powerful and useful. Queries tend to use a lot of `JOIN`s to
+get related data or data based on certain criteria, but `JOIN` performance can
 quickly deteriorate as the data involved grows.
 
 For example, if you want to get a list of projects where the name contains a
@@ -279,7 +279,7 @@ OR namespaces.name ILIKE '%gitlab%';
 ```
 
 Using a large database this query can easily take around 800 milliseconds to
-run. Using a UNION we'd write the following instead:
+run. Using a `UNION` we'd write the following instead:
 
 ```sql
 SELECT projects.*
@@ -301,7 +301,7 @@ This doesn't mean you should start using UNIONs everywhere, but it's something
 to keep in mind when using lots of JOINs in a query and filtering out records
 based on the joined data.
 
-GitLab comes with a `Gitlab::SQL::Union` class that can be used to build a UNION
+GitLab comes with a `Gitlab::SQL::Union` class that can be used to build a `UNION`
 of multiple `ActiveRecord::Relation` objects. You can use this class as
 follows:
 
diff --git a/doc/user/admin_area/analytics/dev_ops_report.md b/doc/user/admin_area/analytics/dev_ops_report.md
index cb94bc8d35b..3c5c646f86c 100644
--- a/doc/user/admin_area/analytics/dev_ops_report.md
+++ b/doc/user/admin_area/analytics/dev_ops_report.md
@@ -39,25 +39,28 @@ collected before this feature is available.
 ## DevOps Adoption **(ULTIMATE SELF)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7 as a [Beta feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta).
-> - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1.
 > - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
 > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59267) in GitLab 14.0.
 > - Enabled on GitLab.com.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-or-enable-devops-adoption). **(ULTIMATE SELF)**
+> - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1.
+> - DAST and SAST metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328033) in GitLab 14.1.
 
 DevOps Adoption shows you which groups within your organization are using the most essential features of GitLab:
 
 - Dev
-  - Issues
-  - Merge Requests
   - Approvals
   - Code owners
+  - Issues
+  - Merge requests
 - Sec
+  - DAST
+  - SAST
   - Scans
 - Ops
-  - Runners
-  - Pipelines
   - Deployments
+  - Pipelines
+  - Runners
 
 When managing groups in the UI, you can add your groups with the **Add group to table**
 button, in the top right hand section the page.
diff --git a/doc/user/admin_area/settings/gitaly_timeouts.md b/doc/user/admin_area/settings/gitaly_timeouts.md
index 6f488efee11..04887906c91 100644
--- a/doc/user/admin_area/settings/gitaly_timeouts.md
+++ b/doc/user/admin_area/settings/gitaly_timeouts.md
@@ -8,23 +8,20 @@ type: reference
 # Gitaly timeouts **(FREE SELF)**
 
 [Gitaly](../../../administration/gitaly/index.md) timeouts are configurable. The timeouts can be
-configured to make sure that long running Gitaly calls don't needlessly take up resources.
+configured to make sure that long-running Gitaly calls don't needlessly take up resources.
 
 To access Gitaly timeout settings:
 
 1. On the top bar, select **Menu >** **{admin}** **Admin**.
 1. On the left sidebar, select **Settings > Preferences**.
-1. Expand the **Gitaly** section.
+1. Expand the **Gitaly timeouts** section.
 
 ## Available timeouts
 
-The following timeouts can be modified:
+The following timeouts are available.
 
-- **Default Timeout Period**. This timeout is the default for most Gitaly calls. It should be shorter than the
-  worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings).
-  Used to make sure that Gitaly calls made within a web request cannot exceed the entire request timeout.
-  Defaults to 55 seconds.
-
-- **Fast Timeout Period**. This is the timeout for very short Gitaly calls. Defaults to 10 seconds.
-- **Medium Timeout Period**. This timeout should be between the default and the fast timeout.
-  Defaults to 30 seconds.
+| Timeout | Default    | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+|:--------|:-----------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Default | 55 seconds | Timeout for most Gitaly calls (not enforced for `git` `fetch` and `push` operations, or Sidekiq jobs). For example, checking if a repository exists on disk. Makes sure that Gitaly calls made within a web request cannot exceed the entire request timeout. It should be shorter than the worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings). If a Gitaly call timeout exceeds the worker timeout, the remaining time from the worker timeout is used to avoid having to terminate the worker. |
+| Fast    | 10 seconds | Timeout for fast Gitaly operations used within requests, sometimes multiple times. For example, checking if a repository exists on disk. If fast operations exceed this threshold, there may be a problem with a storage shard. Failing fast can help maintain the stability of the GitLab instance.                                                                                                                                                                                                                                                                        |
+| Medium  | 30 seconds | Timeout for Gitaly operations that should be fast (possibly within requests) but preferably not used multiple times within a request. For example, loading blobs. Timeout that should be set between Default and Fast.                                                                                                                                                                                                                                                                                                                                                       |
diff --git a/doc/user/group/devops_adoption/index.md b/doc/user/group/devops_adoption/index.md
index 6056af1cb80..e6c9a492c2c 100644
--- a/doc/user/group/devops_adoption/index.md
+++ b/doc/user/group/devops_adoption/index.md
@@ -9,6 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321083) in GitLab 13.11 as a [Beta feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta).
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/333556) in GitLab 14.1.
 > - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1.
+> - DAST and SAST metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328033) in GitLab 14.1.
 
 Prerequisites:
 
@@ -19,16 +20,18 @@ To access Group DevOps Adoption, go to your group and select **Analytics > DevOp
 Group DevOps Adoption shows you how individual groups and sub-groups within your organization use the following features:
 
 - Dev
-  - Issues
-  - Merge Requests
   - Approvals
   - Code owners
+  - Issues
+  - Merge requests
 - Sec
+  - DAST
+  - SAST
   - Scans
 - Ops
-  - Runners
-  - Pipelines
   - Deployments
+  - Pipelines
+  - Runners
 
 When managing groups in the UI, you can add your sub-groups with the **Add sub-group to table**
 button, in the top right hand section of your Groups pages.
diff --git a/doc/user/markdown.md b/doc/user/markdown.md
index db2d6846b7c..809eaf1b8fd 100644
--- a/doc/user/markdown.md
+++ b/doc/user/markdown.md
@@ -507,7 +507,8 @@ This example links to `<wiki_root>/miscellaneous.md`:
 
 GitLab Flavored Markdown renders GitLab-specific references. For example, you can reference
 an issue, a commit, a team member, or even an entire project team. GitLab Flavored Markdown turns
-that reference into a link so you can navigate between them.
+that reference into a link so you can navigate between them. All references to namespaces or 
+projects must use lower-case characters.
 
 Additionally, GitLab Flavored Markdown recognizes certain cross-project references and also has a shorthand
 version to reference other projects from the same namespace.