Add latest changes from gitlab-org/gitlab@master

8 files changed, 114 insertions, 78 deletions

diff --git a/doc/.vale/gitlab/SubstitutionWarning.yml b/doc/.vale/gitlab/SubstitutionWarning.yml
index 61fd0148fd8..77a704eb45a 100644
--- a/doc/.vale/gitlab/SubstitutionWarning.yml
+++ b/doc/.vale/gitlab/SubstitutionWarning.yml
@@ -19,3 +19,9 @@ swap:
   info: information
   repo: repository
   utilize: use
+  owner access: the Owner role
+  owner permission: the Owner role
+  owner permissions: the Owner role
+  maintainer access: the Maintainer role
+  maintainer permission: the Maintainer role
+  maintainer permissions: the Maintainer role
diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index b87a606e349..32fba4da370 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -9,7 +9,7 @@ type: howto
 
 NOTE:
 If your GitLab installation uses external (not managed by Omnibus) PostgreSQL
-instances, the Omnibus roles will not be able to perform all necessary
+instances, the Omnibus roles are unable to perform all necessary
 configuration steps. In this case,
 [follow the Geo with external PostgreSQL instances document instead](external_database.md).
 
@@ -27,8 +27,8 @@ in your testing/production environment.
 
 ## PostgreSQL replication
 
-The GitLab **primary** node where the write operations happen will connect to
-the **primary** database server, and **secondary** nodes will
+The GitLab **primary** node where the write operations happen connects to
+the **primary** database server, and **secondary** nodes 
 connect to their own database servers (which are also read-only).
 
 We recommend using [PostgreSQL replication slots](https://medium.com/@tk512/replication-slots-in-postgresql-b4b03d277c75)
@@ -75,13 +75,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    gitlab-ctl set-geo-primary-node
    ```
 
-   This command will use your defined `external_url` in `/etc/gitlab/gitlab.rb`.
+   This command uses your defined `external_url` in `/etc/gitlab/gitlab.rb`.
 
 1. GitLab 10.4 and up only: Do the following to make sure the `gitlab` database user has a password defined:
 
    NOTE:
    Until FDW settings are removed in GitLab version 14.0, avoid using single or double quotes in the
-   password for PostgreSQL as that will lead to errors when reconfiguring.
+   password for PostgreSQL as that leads to errors when reconfiguring.
 
    Generate a MD5 hash of the desired password:
 
@@ -106,13 +106,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 
 1. Omnibus GitLab already has a [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication)
    called `gitlab_replicator`. You must set the password for this user manually.
-   You will be prompted to enter a password:
+   You are prompted to enter a password:
 
    ```shell
    gitlab-ctl set-replication-password
    ```
 
-   This command will also read the `postgresql['sql_replication_user']` Omnibus
+   This command also reads the `postgresql['sql_replication_user']` Omnibus
    setting in case you have changed `gitlab_replicator` username to something
    else.
 
@@ -154,7 +154,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    echo "External address: $(curl --silent "ipinfo.io/ip")"
    ```
 
-   In most cases, the following addresses will be used to configure GitLab
+   In most cases, the following addresses are used to configure GitLab
    Geo:
 
    | Configuration                           | Address                                               |
@@ -172,7 +172,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    for more details.
 
    NOTE:
-   If you need to use `0.0.0.0` or `*` as the listen_address, you will also need to add
+   If you need to use `0.0.0.0` or `*` as the listen_address, you also need to add
    `127.0.0.1/32` to the `postgresql['md5_auth_cidr_addresses']` setting, to allow Rails to connect through
    `127.0.0.1`. For more information, see [omnibus-5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
 
@@ -262,7 +262,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    `5432` to the **primary** server's private address.
 
 1. A certificate was automatically generated when GitLab was reconfigured. This
-   will be used automatically to protect your PostgreSQL traffic from
+   is used automatically to protect your PostgreSQL traffic from
    eavesdroppers, but to protect against active ("man-in-the-middle") attackers,
    the **secondary** node needs a copy of the certificate. Make a copy of the PostgreSQL
    `server.crt` file on the **primary** node by running this command:
@@ -272,7 +272,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    ```
 
    Copy the output into a clipboard or into a local file. You
-   will need it when setting up the **secondary** node! The certificate is not sensitive
+   need it when setting up the **secondary** node! The certificate is not sensitive
    data.
 
 ### Step 2. Configure the **secondary** server
@@ -325,7 +325,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
       -T server.crt ~gitlab-psql/.postgresql/root.crt
    ```
 
-   PostgreSQL will now only recognize that exact certificate when verifying TLS
+   PostgreSQL now only recognizes that exact certificate when verifying TLS
    connections. The certificate can only be replicated by someone with access
    to the private key, which is **only** present on the **primary** node.
 
@@ -423,7 +423,7 @@ data before running `pg_basebackup`.
 
    WARNING:
    Each Geo **secondary** node must have its own unique replication slot name.
-   Using the same slot name between two secondaries will break PostgreSQL replication.
+   Using the same slot name between two secondaries breaks PostgreSQL replication.
 
    ```shell
    gitlab-ctl replicate-geo-database \
@@ -441,7 +441,7 @@ data before running `pg_basebackup`.
    to list them all, but here are a couple of tips:
 
    - If PostgreSQL is listening on a non-standard port, add `--port=` as well.
-   - If your database is too large to be transferred in 30 minutes, you will need
+   - If your database is too large to be transferred in 30 minutes, you need
      to increase the timeout, e.g., `--backup-timeout=3600` if you expect the
      initial replication to take under an hour.
    - Pass `--sslmode=disable` to skip PostgreSQL TLS authentication altogether
@@ -452,9 +452,9 @@ data before running `pg_basebackup`.
      the instructions above are carefully written to ensure protection against
      both passive eavesdroppers and active "man-in-the-middle" attackers.
    - Change the `--slot-name` to the name of the replication slot
-     to be used on the **primary** database. The script will attempt to create the
+     to be used on the **primary** database. The script attempts to create the
      replication slot automatically if it does not exist.
-   - If you're repurposing an old server into a Geo **secondary** node, you'll need to
+   - If you're repurposing an old server into a Geo **secondary** node, you need to
      add `--force` to the command line.
    - When not in a production machine you can disable backup step if you
      really sure this is what you want by adding `--skip-backup`
@@ -484,7 +484,7 @@ subject to change without notice.
 This experimental implementation has the following limitations:
 
 - Whenever `gitlab-ctl reconfigure` runs on a Patroni Leader instance, there's a
-  chance the node will be demoted due to the required short-time restart. To
+  chance of the node be demoted due to the required short-time restart. To
   avoid this, you can pause auto-failover by running `gitlab-ctl patroni pause`.
   After a reconfigure, it resumes on its own.
 
@@ -530,7 +530,7 @@ Leader instance**:
 
    # You need one entry for each secondary, with a unique name following PostgreSQL slot_name constraints:
    #
-   # Configuration syntax will be: 'unique_slotname' => { 'type' => 'physical' },
+   # Configuration syntax is: 'unique_slotname' => { 'type' => 'physical' },
    # We don't support setting a permanent replication slot for logical replication type
    patroni['replication_slots'] = {
      'geo_secondary' => { 'type' => 'physical' }
@@ -559,14 +559,14 @@ Leader instance**:
 #### Step 2. Configure the internal load balancer on the primary site
 
 To avoid reconfiguring the Standby Leader on the secondary site whenever a new
-Leader is elected on the primary site, we'll need to set up a TCP internal load
-balancer which will give a single endpoint for connecting to the Patroni
+Leader is elected on the primary site, we need to set up a TCP internal load
+balancer which gives a single endpoint for connecting to the Patroni
 cluster's Leader.
 
 The Omnibus GitLab packages do not include a Load Balancer. Here's how you
 could do it with [HAProxy](https://www.haproxy.org/).
 
-The following IPs and names will be used as an example:
+The following IPs and names are used as an example:
 
 - `10.6.0.21`: Patroni 1 (`patroni1.internal`)
 - `10.6.0.21`: Patroni 2 (`patroni2.internal`)
@@ -662,7 +662,7 @@ Follow the minimal configuration for the PgBouncer node:
 
 NOTE:
 If you are converting a secondary site to a Patroni Cluster, you must start
-on the PostgreSQL instance. It will become the Patroni Standby Leader instance,
+on the PostgreSQL instance. It becomes the Patroni Standby Leader instance,
 and then you can switchover to another replica if you need.
 
 For each Patroni instance on the secondary site:
@@ -734,7 +734,7 @@ For each Patroni instance on the secondary site:
 
 1. Before migrating, it is recommended that there is no replication lag between the primary and secondary sites and that replication is paused. In GitLab 13.2 and later, you can pause and resume replication with `gitlab-ctl geo-replication-pause` and `gitlab-ctl geo-replication-resume` on a Geo secondary database node.
 1. Follow the [instructions to migrate repmgr to Patroni](../../postgresql/replication_and_failover.md#switching-from-repmgr-to-patroni). When configuring Patroni on each primary site database node, add `patroni['replication_slots'] = { '<slot_name>' => 'physical' }`
-to `gitlab.rb` where `<slot_name>` is the name of the replication slot for your Geo secondary. This will ensure that Patroni recognizes the replication slot as permanent and will not drop it upon restarting.
+to `gitlab.rb` where `<slot_name>` is the name of the replication slot for your Geo secondary. This ensures that Patroni recognizes the replication slot as permanent and not drop it upon restarting.
 1. If database replication to the secondary was paused before migration, resume replication once Patroni is confirmed working on the primary.
 
 ### Migrating a single PostgreSQL node to Patroni
@@ -750,7 +750,7 @@ With Patroni it's now possible to support that. In order to migrate the existing
 1. [Configure a Standby Cluster](#step-4-configure-a-standby-cluster-on-the-secondary-site)
    on that single node machine.
 
-You will end up with a "Standby Cluster" with a single node. That allows you to later on add additional Patroni nodes
+You end up with a "Standby Cluster" with a single node. That allows you to later on add additional Patroni nodes
 by following the same instructions above.
 
 ### Configuring Patroni cluster for the tracking PostgreSQL database
@@ -934,8 +934,8 @@ Patroni implementation on Omnibus that do not allow us to manage two different
 clusters on the same machine, we recommend setting up a new Patroni cluster for
 the tracking database by following the same instructions above.
 
-The secondary nodes will backfill the new tracking database, and no data
-synchronization will be required.
+The secondary nodes backfill the new tracking database, and no data
+synchronization is required.
 
 ## Troubleshooting
 
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index a94d02e8d69..50db8509882 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -15,6 +15,7 @@ use the `#docs-processes` channel.
 In addition to this page, the following resources can help you craft and contribute to documentation:
 
 - [Doc contribution guidelines](../index.md)
+- [A-Z word list](word_list.md)
 - [Doc style and consistency testing](../testing.md)
 - [UI text guidelines](https://design.gitlab.com/content/error-messages/)
 - [GitLab Handbook style guidelines](https://about.gitlab.com/handbook/communication/#writing-style-guidelines)
@@ -371,7 +372,7 @@ Capitalize names of:
 - Methods or methodologies. For example, Continuous Integration,
   Continuous Deployment, Scrum, and Agile.
 
-Follow the capitalization style listed at the [authoritative source](#links-to-external-documentation)
+Follow the capitalization style listed at the authoritative source
 for the entity, which may use non-standard case styles. For example: GitLab and
 npm.
 
@@ -499,41 +500,6 @@ You can use these fake tokens as examples:
 | Health check token    | `Tu7BgjR9qeZTEyRzGG2P`                                             |
 | Request profile token | `7VgpS4Ax5utVD2esNstz`                                             |
 
-### Usage list
-<!-- vale off -->
-
-| Usage                 | Guidance |
-|-----------------------|----------|
-| above                 | Try to avoid extra words when referring to an example or table in a documentation page, but if required, use **previously** instead. |
-| admin, admin area     | Use **administration**, **administrator**, **administer**, or **Admin Area** instead. ([Vale](../testing.md#vale) rule: [`Admin.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Admin.yml)) |
-| allow, enable         | Try to avoid, unless you are talking about security-related features. For example, instead of "This feature allows you to create a pipeline," use "Use this feature to create a pipeline." This phrasing is more active and is from the user perspective, rather than the person who implemented the feature. [View details](https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/a/allow-allows). |
-| and/or                | Use **or** instead, or another sensible construction. |
-| below                 | Try to avoid extra words when referring to an example or table in a documentation page, but if required, use **following** instead. |
-| currently             | Do not use when talking about the product or its features. The documentation describes the product as it is today. ([Vale](../testing.md#vale) rule: [`CurrentStatus.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/CurrentStatus.yml)) |
-| easily                | Do not use. If the user doesn't find the process to be these things, we lose their trust. |
-| e.g.                  | Do not use Latin abbreviations. Use **for example**, **such as**, **for instance**, or **like** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml)) |
-| future tense          | When possible, use present tense instead. For example, use `after you execute this command, GitLab displays the result` instead of `after you execute this command, GitLab will display the result`. ([Vale](../testing.md#vale) rule: [`FutureTense.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FutureTense.yml)) |
-| handy                 | Do not use. If the user doesn't find the process to be these things, we lose their trust. |
-| high availability, HA | Do not use. Instead, direct readers to the GitLab [reference architectures](../../../administration/reference_architectures/index.md) for information about configuring GitLab for handling greater amounts of users. |
-| I                     | Do not use first-person singular. Use **you**, **we**, or **us** instead. ([Vale](../testing.md#vale) rule: [`FirstPerson.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FirstPerson.yml)) |
-| i.e.                  | Do not use Latin abbreviations. Use **that is** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml)) |
-| jargon                | Do not use. Define the term or [link to a definition](#links-to-external-documentation). |
-| may, might            | **Might** means something has the probability of occurring. **May** gives permission to do something. Consider **can** instead of **may**. |
-| me, myself, mine      | Do not use first-person singular. Use **you**, **we**, or **us** instead. ([Vale](../testing.md#vale) rule: [`FirstPerson.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FirstPerson.yml)) |
-| permissions           | Do not use roles and permissions interchangeably. Each user is assigned a role. Each role includes a set of permissions. |
-| please                | Do not use. For details, see the [Microsoft style guide](https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/p/please). |
-| profanity             | Do not use. Doing so may negatively affect other users and contributors, which is contrary to the GitLab value of [Diversity, Inclusion, and Belonging](https://about.gitlab.com/handbook/values/#diversity-inclusion). |
-| roles                 | Do not use roles and permissions interchangeably. Each user is assigned a role. Each role includes a set of permissions. |
-| scalability           | Do not use when talking about increasing GitLab performance for additional users. The words scale or scaling are sometimes acceptable, but references to increasing GitLab performance for additional users should direct readers to the GitLab [reference architectures](../../../administration/reference_architectures/index.md) page. |
-| simply                | Do not use. If the user doesn't find the process to be these things, we lose their trust. |
-| slashes               | Instead of **and/or**, use **or** or another sensible construction. This rule also applies to other slashes, like **follow/unfollow**. Some exceptions (like **CI/CD**) are allowed. |
-| subgroup              | Use instead of `sub-group`. |
-| that                  | Do not use. Example: `the file that you save` can be `the file you save`. |
-| useful                | Do not use. If the user doesn't find the process to be these things, we lose their trust. |
-| utilize               | Do not use. Use **use** instead. It's more succinct and easier for non-native English speakers to understand. |
-| via                   | Do not use Latin abbreviations. Use **with**, **through**, or **by using** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml)) |
-
-<!-- vale on -->
 ### Contractions
 
 Contractions are encouraged, and can create a friendly and informal tone,
@@ -1592,7 +1558,7 @@ GitLab users are [assigned roles](../../../user/permissions.md) that confer spec
 - _Maintainer_ is an example of a role.
 - _Create new issue_ is an example of a permission.
 
-[Do not use](#usage-list) these terms interchangeably.
+[Do not use](word_list.md) these terms interchangeably.
 
 ## GitLab versions
 
diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md
new file mode 100644
index 00000000000..6824d065aea
--- /dev/null
+++ b/doc/development/documentation/styleguide/word_list.md
@@ -0,0 +1,45 @@
+---
+stage: none
+group: Style Guide
+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/#assignments
+description: 'Writing styles, markup, formatting, and other standards for GitLab Documentation.'
+---
+
+# A-Z word list
+
+To help ensure consistency in the documentation, follow this guidance.
+
+<!-- vale off -->
+
+| Usage                 | Guidance |
+|-----------------------|----------|
+| above                 | Try to avoid extra words when referring to an example or table in a documentation page, but if required, use **previously** instead. |
+| admin, admin area     | Use **administration**, **administrator**, **administer**, or **Admin Area** instead. ([Vale](../testing.md#vale) rule: [`Admin.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Admin.yml)) |
+| allow, enable         | Try to avoid, unless you are talking about security-related features. For example, instead of "This feature allows you to create a pipeline," use "Use this feature to create a pipeline." This phrasing is more active and is from the user perspective, rather than the person who implemented the feature. [View details](https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/a/allow-allows). |
+| and/or                | Use **or** instead, or another sensible construction. |
+| below                 | Try to avoid extra words when referring to an example or table in a documentation page, but if required, use **following** instead. |
+| currently             | Do not use when talking about the product or its features. The documentation describes the product as it is today. ([Vale](../testing.md#vale) rule: [`CurrentStatus.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/CurrentStatus.yml)) |
+| easily                | Do not use. If the user doesn't find the process to be these things, we lose their trust. |
+| e.g.                  | Do not use Latin abbreviations. Use **for example**, **such as**, **for instance**, or **like** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml)) |
+| future tense          | When possible, use present tense instead. For example, use `after you execute this command, GitLab displays the result` instead of `after you execute this command, GitLab will display the result`. ([Vale](../testing.md#vale) rule: [`FutureTense.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FutureTense.yml)) |
+| handy                 | Do not use. If the user doesn't find the process to be these things, we lose their trust. |
+| high availability, HA | Do not use. Instead, direct readers to the GitLab [reference architectures](../../../administration/reference_architectures/index.md) for information about configuring GitLab for handling greater amounts of users. |
+| I                     | Do not use first-person singular. Use **you**, **we**, or **us** instead. ([Vale](../testing.md#vale) rule: [`FirstPerson.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FirstPerson.yml)) |
+| i.e.                  | Do not use Latin abbreviations. Use **that is** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml)) |
+| jargon                | Do not use. Define the term or link to a definition. |
+| may, might            | **Might** means something has the probability of occurring. **May** gives permission to do something. Consider **can** instead of **may**. |
+| me, myself, mine      | Do not use first-person singular. Use **you**, **we**, or **us** instead. ([Vale](../testing.md#vale) rule: [`FirstPerson.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FirstPerson.yml)) |
+| permissions           | Do not use roles and permissions interchangeably. Each user is assigned a role. Each role includes a set of permissions. |
+| please                | Do not use. For details, see the [Microsoft style guide](https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/p/please). |
+| profanity             | Do not use. Doing so may negatively affect other users and contributors, which is contrary to the GitLab value of [Diversity, Inclusion, and Belonging](https://about.gitlab.com/handbook/values/#diversity-inclusion). |
+| roles                 | Do not use roles and permissions interchangeably. Each user is assigned a role. Each role includes a set of permissions. |
+| scalability           | Do not use when talking about increasing GitLab performance for additional users. The words scale or scaling are sometimes acceptable, but references to increasing GitLab performance for additional users should direct readers to the GitLab [reference architectures](../../../administration/reference_architectures/index.md) page. |
+| simply                | Do not use. If the user doesn't find the process to be these things, we lose their trust. |
+| slashes               | Instead of **and/or**, use **or** or another sensible construction. This rule also applies to other slashes, like **follow/unfollow**. Some exceptions (like **CI/CD**) are allowed. |
+| subgroup              | Use instead of `sub-group`. |
+| that                  | Do not use. Example: `the file that you save` can be `the file you save`. |
+| useful                | Do not use. If the user doesn't find the process to be these things, we lose their trust. |
+| utilize               | Do not use. Use **use** instead. It's more succinct and easier for non-native English speakers to understand. |
+| via                   | Do not use Latin abbreviations. Use **with**, **through**, or **by using** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml)) |
+
+<!-- vale on -->
diff --git a/doc/operations/incident_management/incidents.md b/doc/operations/incident_management/incidents.md
index 849f2fdbb02..055b8392cab 100644
--- a/doc/operations/incident_management/incidents.md
+++ b/doc/operations/incident_management/incidents.md
@@ -204,7 +204,9 @@ un-threaded and ordered chronologically, newest to oldest:
 You can enable the Service Level Agreement Countdown timer on incidents to track
 the Service Level Agreements (SLAs) you hold with your customers. The timer is
 automatically started when the incident is created, and shows the time
-remaining before the SLA period expires. To configure the timer:
+remaining before the SLA period expires. The timer is also dynamically updated
+every 15 minutes so you do not have to refresh the page to see the time remaining.
+To configure the timer:
 
 1. Navigate to **Settings > Operations**.
 1. Scroll to **Incidents** and click **Expand**, then select the
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index dcaefd39dde..336fffc380b 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -173,9 +173,10 @@ You can [configure](#customizing-the-container-scanning-settings) analyzers by u
 | `ADDITIONAL_CA_CERT_BUNDLE`    | `""`          | Bundle of CA certs that you want to trust. See [Using a custom SSL CA certificate authority](#using-a-custom-ssl-ca-certificate-authority) for more details. | All |
 | `CI_APPLICATION_REPOSITORY`    | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG` | Docker repository URL for the image to be scanned. | All |
 | `CI_APPLICATION_TAG`           | `$CI_COMMIT_SHA` | Docker repository tag for the image to be scanned. | All |
-| `CS_ANALYZER_IMAGE`             | `$SECURE_ANALYZERS_PREFIX/$CS_PROJECT:$CS_MAJOR_VERSION`           | Docker image of the analyzer. | All |
-| `CS_DOCKER_INSECURE`              | `"false"`     | Allow access to secure Docker registries using HTTPS without validating the certificates. | All |
-| `CS_REGISTRY_INSECURE`            | `"false"`     | Allow access to insecure registries (HTTP only). Should only be set to `true` when testing the image locally. | All |
+| `CS_ANALYZER_IMAGE`            | `$SECURE_ANALYZERS_PREFIX/$CS_PROJECT:$CS_MAJOR_VERSION`           | Docker image of the analyzer. | All |
+| `CS_DOCKER_INSECURE`           | `"false"`     | Allow access to secure Docker registries using HTTPS without validating the certificates. | All |
+| `CS_REGISTRY_INSECURE`         | `"false"`     | Allow access to insecure registries (HTTP only). Should only be set to `true` when testing the image locally. | All |
+| `CS_SEVERITY_THRESHOLD`        | `UNKNOWN`     | Severity level threshold. The scanner outputs vulnerabilities with severity level higher than or equal to this threshold. Supported levels are Unknown, Low, Medium, High, and Critical. | Trivy |
 | `DOCKER_IMAGE`                 | `$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG` | The Docker image to be scanned. If set, this variable overrides the `$CI_APPLICATION_REPOSITORY` and `$CI_APPLICATION_TAG` variables. | All |
 | `DOCKER_PASSWORD`              | `$CI_REGISTRY_PASSWORD` | Password for accessing a Docker registry requiring authentication. | All |
 | `DOCKER_USER`                  | `$CI_REGISTRY_USER` | Username for accessing a Docker registry requiring authentication. | All |
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index fed8baa8bcc..b2e26a6e097 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -210,11 +210,9 @@ request contains a denied license. For more details, see [Enabling license appro
 Prerequisites:
 
 - At least one [security scanner job](#security-scanning-tools) must be enabled.
-- Maintainer or Owner [permissions](../permissions.md#project-members-permissions).
+- Maintainer or Owner [role](../permissions.md#project-members-permissions).
 
-For this approval group, you must set the number of approvals required to greater than zero. You
-must have Maintainer or Owner [permissions](../permissions.md#project-members-permissions)
-to manage approval rules.
+For this approval group, you must set the number of approvals required to greater than zero.
 
 Follow these steps to enable `Vulnerability-Check`:
 
diff --git a/doc/user/packages/package_registry/index.md b/doc/user/packages/package_registry/index.md
index f04f6f1316e..5f3eb4d9c5c 100644
--- a/doc/user/packages/package_registry/index.md
+++ b/doc/user/packages/package_registry/index.md
@@ -40,14 +40,16 @@ authenticate with GitLab by using the `CI_JOB_TOKEN`.
 
 CI/CD templates, which you can use to get started, are in [this repository](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).
 
-Learn more about using CI/CD to build:
+Learn more about using the GitLab Package Registry with CI/CD:
 
-- [Composer packages](../composer_repository/index.md#publish-a-composer-package-by-using-cicd)
-- [Conan packages](../conan_repository/index.md#publish-a-conan-package-by-using-cicd)
-- [Generic packages](../generic_packages/index.md#publish-a-generic-package-by-using-cicd)
-- [Maven packages](../maven_repository/index.md#create-maven-packages-with-gitlab-cicd)
-- [npm packages](../npm_registry/index.md#publish-an-npm-package-by-using-cicd)
-- [NuGet packages](../nuget_repository/index.md#publish-a-nuget-package-by-using-cicd)
+- [Composer](../composer_repository/index.md#publish-a-composer-package-by-using-cicd)
+- [Conan](../conan_repository/index.md#publish-a-conan-package-by-using-cicd)
+- [Generic](../generic_packages/index.md#publish-a-generic-package-by-using-cicd)
+- [Maven](../maven_repository/index.md#create-maven-packages-with-gitlab-cicd)
+- [npm](../npm_registry/index.md#publish-an-npm-package-by-using-cicd)
+- [NuGet](../nuget_repository/index.md#publish-a-nuget-package-by-using-cicd)
+- [PyPI](../pypi_repository/#authenticate-with-a-ci-job-token)
+- [RubyGems](../rubygems_registry/#authenticate-with-a-ci-job-token)
 
 If you use CI/CD to build a package, extended activity information is displayed
 when you view the package details:
@@ -81,6 +83,22 @@ To delete a package in the UI, from your group or project:
 
 The package is permanently deleted.
 
+## Delete files associated with a package
+
+To delete package files, you must have suitable [permissions](../../permissions.md).
+
+You can delete packages by using [the API](../../../api/packages.md#delete-a-package-file) or the UI.
+
+To delete package files in the UI, from your group or project:
+
+1. Go to **Packages & Registries > Package Registry**.
+1. Find the name of the package you want to delete.
+1. Select the package to view additional details.
+1. Find the name of the file you would like to delete. 
+1. Expand the ellipsis and select **Delete file**.
+
+The package files are permanently deleted.
+
 ## Disable the Package Registry
 
 The Package Registry is automatically enabled.