Add latest changes from gitlab-org/gitlab@master

16 files changed, 127 insertions, 72 deletions

diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 22eabe167d6..7a2a136187e 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -118,7 +118,7 @@ The OpenID Connect provides you with a client's details and secret for you to us
      If you do not provide this value, or the field with the configured value is missing
      from the `user_info.raw_attributes` details, `uid` uses the `sub` field.
    - `send_scope_to_token_endpoint` is `true` by default, so the `scope` parameter
-     is normally included in requests to the token endpoint.
+     is usually included in requests to the token endpoint.
      However, if your OpenID Connect provider does not accept the `scope` parameter
      in such requests, set this to `false`.
    - `client_options` are the OpenID Connect client-specific options. Specifically:
diff --git a/doc/administration/logs/log_parsing.md b/doc/administration/logs/log_parsing.md
index 0439d4967cb..84c517e6120 100644
--- a/doc/administration/logs/log_parsing.md
+++ b/doc/administration/logs/log_parsing.md
@@ -120,6 +120,12 @@ jq 'select(.queue_duration_s > 10000)' <FILE>
 jq -s 'map(select(.gitaly_calls != null)) | sort_by(-.gitaly_calls) | limit(10; .[])' <FILE>
 ```
 
+#### Output a specific time range
+
+```shell
+jq 'select(.time >= "2023-01-10T00:00:00Z" and .time <= "2023-01-10T12:00:00Z")' <FILE>
+```
+
 ### Parsing `gitlab-rails/production_json.log`
 
 #### Print the top three controller methods by request volume and their three longest durations
diff --git a/doc/administration/package_information/signed_packages.md b/doc/administration/package_information/signed_packages.md
index e4566be7534..638dd7820b8 100644
--- a/doc/administration/package_information/signed_packages.md
+++ b/doc/administration/package_information/signed_packages.md
@@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Package Signatures **(FREE SELF)**
 
-As of the release of GitLab 9.5 on August 22, 2017, GitLab provides signed Omnibus GitLab packages for RPM and DEB based distributions. This means that all packages provided on <https://packages.gitlab.com> are signed, starting with `9.5.0`, and all future versions of supported branches (for example `9.3.x` and `9.4.x` after August 22, 2017). Any package version prior to August 22, 2017, will not be signed. Pass the appropriate argument to your package manager. (Example: `yum --nogpgcheck`)
-
 Omnibus GitLab packages produced by GitLab are created via the [Omnibus](https://github.com/chef/omnibus) tool, for which GitLab has added DEB signing via `debsigs` in [our own fork](https://gitlab.com/gitlab-org/omnibus). This addition, combined with the existing functionality of RPM signing, allows GitLab to provide signed packages for all supported distributions using DEB or RPM.
 
 These packages are produced by the GitLab CI process, as found in the  [Omnibus GitLab project](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/.gitlab-ci.yml), prior to their delivery to <https://packages.gitlab.com> to ensure provide assurance that the packages are not altered prior to delivery to our community.
diff --git a/doc/api/projects.md b/doc/api/projects.md
index bd3b13f517c..5b9ce203141 100644
--- a/doc/api/projects.md
+++ b/doc/api/projects.md
@@ -6,20 +6,14 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Projects API **(FREE)**
 
-Interact with [projects](../user/project/index.md) using the REST API.
+Interact with [projects](../user/project/index.md) by using the REST API.
 
 ## Project visibility level
 
 A project in GitLab can be private, internal, or public.
 The visibility level is determined by the `visibility` field in the project.
 
-Values for the project visibility level are:
-
-- `private`: project access must be granted explicitly to each user.
-- `internal`: the project can be cloned by any authenticated user except [external users](../user/admin_area/external_users.md).
-- `public`: the project can be accessed without any authentication.
-
-For more, read [Project visibility](../user/public_access.md).
+For details, see [Project visibility](../user/public_access.md).
 
 ## Project merge method
 
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index 20bdd059a85..2d5e3d5a26f 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -369,7 +369,7 @@ are done to the services as well, making these incompatible.
 
 #### Use the Docker executor with Docker socket binding
 
-To make Docker available in the context of the image, you will need to mount
+To make Docker available in the context of the image, you need to mount
 `/var/run/docker.sock` into the launched containers. To do this with the Docker
 executor, you need to add `"/var/run/docker.sock:/var/run/docker.sock"` to the
 [Volumes in the `[runners.docker]` section](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#volumes-in-the-runnersdocker-section).
diff --git a/doc/ci/docker/using_docker_images.md b/doc/ci/docker/using_docker_images.md
index 0ba510acdbc..022aa7c3093 100644
--- a/doc/ci/docker/using_docker_images.md
+++ b/doc/ci/docker/using_docker_images.md
@@ -158,7 +158,7 @@ a useless shell layer. However, that does not work for all Docker versions.
 - For Docker 17.03 and earlier, the `entrypoint` can be set to
   `/bin/sh -c`, `/bin/bash -c`, or an equivalent shell available in the image.
 
-The syntax of `image:entrypoint` is similar to [Dockerfile's `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint).
+The syntax of `image:entrypoint` is similar to [Dockerfile `ENTRYPOINT`](https://docs.docker.com/engine/reference/builder/#entrypoint).
 
 Let's assume you have a `super/sql:experimental` image with a SQL database
 in it. You want to use it as a base image for your job because you
@@ -453,7 +453,7 @@ registries to the `"credHelpers"` hash.
 
 ### Use checksum to keep your image secure
 
-We recommend using the image checksum in your job definition in your `.gitlab-ci.yml` file to verify the integrity of the image. A failed image integrity verification will prevent you from using a modified container.
+We recommend using the image checksum in your job definition in your `.gitlab-ci.yml` file to verify the integrity of the image. A failed image integrity verification prevents you from using a modified container.
 
 To use the image checksum you have to append the checksum at the end:
 
diff --git a/doc/ci/resource_groups/index.md b/doc/ci/resource_groups/index.md
index b46008abb07..7cf71f2a3ea 100644
--- a/doc/ci/resource_groups/index.md
+++ b/doc/ci/resource_groups/index.md
@@ -235,7 +235,7 @@ If the process mode is `oldest_first`, it executes the jobs from the oldest pipe
 
 However, a child pipeline also requires a resource from the `production` resource group.
 Because the child pipeline is newer than the parent pipeline, the child pipeline
-waits until the `deploy` job is finished, something that will never happen.
+waits until the `deploy` job is finished, something that never happens.
 
 In this case, you should specify the `resource_group` keyword in the parent pipeline configuration instead:
 
diff --git a/doc/install/postgresql_extensions.md b/doc/install/postgresql_extensions.md
index 2d6a9411f25..ea6de690426 100644
--- a/doc/install/postgresql_extensions.md
+++ b/doc/install/postgresql_extensions.md
@@ -24,14 +24,14 @@ extensions into all secondary tracking databases (defaults to `gitlabhq_geo_prod
 |--------------|------------------------|
 | `plpgsql`    | 9.0                    |
 
-In order to install extensions, PostgreSQL requires the user to have superuser privileges.
+To install extensions, PostgreSQL requires the user to have superuser privileges.
 Typically, the GitLab database user is not a superuser. Therefore, regular database migrations
 cannot be used in installing extensions and instead, extensions have to be installed manually
 prior to upgrading GitLab to a newer version.
 
 ## Installing PostgreSQL extensions manually
 
-In order to install a PostgreSQL extension, this procedure should be followed:
+To install a PostgreSQL extension, this procedure should be followed:
 
 1. Connect to the GitLab PostgreSQL database using a superuser, for example:
 
diff --git a/doc/integration/glab/index.md b/doc/integration/glab/index.md
index e71f49905c8..621472a2083 100644
--- a/doc/integration/glab/index.md
+++ b/doc/integration/glab/index.md
@@ -17,7 +17,7 @@ switching between windows and browser tabs.
 ![command example](img/glabgettingstarted.gif)
 
 The GitLab CLI uses commands structured like `glab <command> <subcommand> [flags]`
-to perform many of the actions you normally do from the GitLab user interface:
+to perform many of the actions you usually do from the GitLab user interface:
 
 ```shell
 # Sign in
diff --git a/doc/integration/jira/connect-app.md b/doc/integration/jira/connect-app.md
index 9e75e248d23..04fd36079ec 100644
--- a/doc/integration/jira/connect-app.md
+++ b/doc/integration/jira/connect-app.md
@@ -88,7 +88,9 @@ To create an OAuth application:
 1. On the top bar, select **Main menu > Admin**.
 1. On the left sidebar, select **Applications** (`/admin/applications`).
 1. Select **New application**.
-1. In **Redirect URI**, enter `https://gitlab.com/-/jira_connect/oauth_callbacks`.
+1. In **Redirect URI**:
+   - If you're installing the app from the official marketplace listing, enter `https://gitlab.com/-/jira_connect/oauth_callbacks`.
+   - If you're installing the app manually, enter `<instance_url>/-/jira_connect/oauth_callbacks` and replace `<instance_url>` with the URL of your instance.
 1. Clear the **Confidential** checkbox.
 <!-- markdownlint-disable MD044 -->
 1. In **Scopes**, select the **api** checkbox only.
diff --git a/doc/integration/mattermost/index.md b/doc/integration/mattermost/index.md
index df6130a7540..42592a0dff2 100644
--- a/doc/integration/mattermost/index.md
+++ b/doc/integration/mattermost/index.md
@@ -307,7 +307,7 @@ These settings can also be configured in `/var/opt/gitlab/mattermost/config.json
 
 Enabling this feature allows users to control how often they receive email notifications.
 
-Email batching can be enabled in the Mattermost **System Console** by going to the **Environment > SMTP** tab, and setting the **Enable Email Batching** setting to **True**.
+Email batching can be enabled in the Mattermost **System Console** by navigating to the **Environment > SMTP** tab, and setting the **Enable Email Batching** setting to **True**.
 
 This setting can also be configured in `/var/opt/gitlab/mattermost/config.json`.
 
@@ -360,7 +360,7 @@ When upgrading the Mattermost version, it is essential to check the
 for Mattermost to address any changes or migrations that need to be performed.
 
 Starting with GitLab 11.0, GitLab Mattermost can be upgraded through the regular Omnibus GitLab update process. When upgrading previous versions of
-GitLab, the update process can only be used if Mattermost configuration settings have not been changed outside of GitLab. That is, no changes to Mattermost's `config.json`
+GitLab, the update process can only be used if Mattermost configuration settings have not been changed outside of GitLab. That is, no changes to the Mattermost `config.json`
 file have been made - either directly or via the Mattermost **System Console**, which saves changes to `config.json`.
 
 If you are upgrading to at least GitLab 11.0 or have only configured Mattermost using `gitlab.rb`, you can upgrade GitLab using Omnibus and then run `gitlab-ctl reconfigure` to upgrade GitLab Mattermost to the latest version.
@@ -402,7 +402,7 @@ generates the `config.json` file, and instead passes limited configuration setti
 The settings that continue to be supported in `gitlab.rb` can be found in
 [`gitlab.rb.template`](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template).
 
-From GitLab 11.0, other Mattermost settings can be configured through Mattermost's System Console,
+From GitLab 11.0, other Mattermost settings can be configured through the Mattermost System Console,
 by editing `/var/opt/gitlab/mattermost/config.json`, or by using `mattermost['env']` in `gitlab.rb`.
 
 If you would like to keep configuring Mattermost using `gitlab.rb`, you can take the following actions
@@ -490,9 +490,9 @@ If you encounter any issues [visit the GitLab Mattermost troubleshooting forum](
 
 If you choose to upgrade Mattermost outside of the Omnibus GitLab automation, [follow this guide](https://docs.mattermost.com/administration/upgrade.html).
 
-## OAuth2 sequence diagram
+## OAuth 2.0 sequence diagram
 
-The following image is a sequence diagram for how GitLab works as an OAuth2
+The following image is a sequence diagram for how GitLab works as an OAuth 2.0
 provider for Mattermost. You can use this to troubleshoot errors
 in getting the integration to work:
 
@@ -520,7 +520,7 @@ sequenceDiagram
 
 ## Community support resources
 
-For help and support around your GitLab Mattermost deployment please see:
+For help and support around your GitLab Mattermost deployment, see:
 
 - [Troubleshooting Mattermost issues](https://docs.mattermost.com/install/troubleshooting.html).
 - [Mattermost GitLab Issues Support Handbook](https://docs.mattermost.com/process/support.html?highlight=omnibus#gitlab-issues).
diff --git a/doc/raketasks/backup_gitlab.md b/doc/raketasks/backup_gitlab.md
index ffa67c6b4a9..fd88529807f 100644
--- a/doc/raketasks/backup_gitlab.md
+++ b/doc/raketasks/backup_gitlab.md
@@ -216,7 +216,7 @@ To ensure the generated archive is transferable by rsync, you can set the `GZIP_
 option. This sets the `--rsyncable` option to `gzip`, which is useful only in
 combination with setting [the Backup filename option](#backup-filename).
 
-Note that the `--rsyncable` option in `gzip` isn't guaranteed to be available
+The `--rsyncable` option in `gzip` isn't guaranteed to be available
 on all distributions. To verify that it's available in your distribution, run
 `gzip --help` or consult the man pages.
 
@@ -468,7 +468,7 @@ gitlab_rails['backup_upload_storage_options'] = {
 
 ##### SSE-KMS
 
-To enable SSE-KMS, you'll need the
+To enable SSE-KMS, you need the
 [KMS key via its Amazon Resource Name (ARN) in the `arn:aws:kms:region:acct-id:key/key-id` format](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html).
 Under the `backup_upload_storage_options` configuration setting, set:
 
diff --git a/doc/user/analytics/value_streams_dashboard.md b/doc/user/analytics/value_streams_dashboard.md
index 1de26749deb..f8cfb1bf06b 100644
--- a/doc/user/analytics/value_streams_dashboard.md
+++ b/doc/user/analytics/value_streams_dashboard.md
@@ -16,6 +16,9 @@ The Value Streams Dashboard is a customizable dashboard to enable decision-maker
 This page is a work in progress, and we're updating the information as we add more features.
 For more information, see the [Value Stream Management category direction page](https://about.gitlab.com/direction/plan/value_stream_management/).
 
+After the feature flag is enabled, to open the new page, append this path `/analytics/dashboards` to the group URL
+(for example, `https://gitlab.com/groups/gitlab-org/-/analytics/dashboards`).
+
 ## Initial use case
 
 Our initial use case is focused on providing the ability to compare software delivery metrics.
@@ -59,3 +62,16 @@ For example, the parameter `query=gitlab-org/gitlab-foss,gitlab-org/gitlab,gitla
 - `gitlab-org` group
 - `gitlab-ui` project
 - `gitlab-org/plan-stage` subgroup
+
+## Dashboard metrics and drill-down reports
+
+| Metric | Description | Drill-down report | Documentation page |
+| ------ | ----------- | --------------- | ------------------ |
+| Deployment frequency | Average number of deployments to production per day. This metric measures how often value is delivered to end users. | [Deployment frequency tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=deployment-frequency) | [Deployment frequency](dora_metrics.md#deployment-frequency) |
+| Lead time for changes | The time to successfully deliver a commit into production. This metric reflects the efficiency of CI/CD pipelines. | [Lead time tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=lead-time) | [Lead time for changes](dora_metrics.md#lead-time-for-changes) |
+| Time to restore service | The time it takes an organization to recover from a failure in production. | [Time to restore service tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=time-to-restore-service) | [Time to restore service](dora_metrics.md#time-to-restore-service) |
+| Change failure rate | Percentage of deployments that cause an incident in production. | [Change failure rate tab](https://gitlab.com/groups/gitlab-org/-/analytics/ci_cd?tab=change-failure-rate) | [Change failure rate](dora_metrics.md#change-failure-rate) |
+| VSA Lead time | Median time from issue created to issue closed. | [Value Stream Analytics](https://gitlab.com/groups/gitlab-org/-/analytics/value_stream_analytics) | [View the lead time and cycle time for issues](value_stream_analytics.md#view-the-lead-time-and-cycle-time-for-issues) |
+| VSA Cycle time | Median time from the earliest commit of a linked issue's merge request to when that issue is closed. | [VSA overview](https://gitlab.com/groups/gitlab-org/-/analytics/value_stream_analytics) | [View the lead time and cycle time for issues](value_stream_analytics.md#view-the-lead-time-and-cycle-time-for-issues) |
+| New issues | Number of new issues created. | [Issue Analytics](https://gitlab.com/groups/gitlab-org/-/issues_analytics) | Issue analytics [for projects](issue_analytics.md) and [for groups](../../user/group/issues_analytics/index.md) |
+| Number of deploys | Total number of deploys to production. | [Merge Request Analytics](https://gitlab.com/gitlab-org/gitlab/-/analytics/merge_request_analytics) | [Merge request analytics](merge_request_analytics.md) |
diff --git a/doc/user/application_security/dast_api/index.md b/doc/user/application_security/dast_api/index.md
index 4c324033140..0144c37c3ff 100644
--- a/doc/user/application_security/dast_api/index.md
+++ b/doc/user/application_security/dast_api/index.md
@@ -5,13 +5,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference, howto
 ---
 
-# DAST API **(ULTIMATE)**
+# DAST API analyzer **(ULTIMATE)**
 
 > DAST API analyzer [became the default analyzer for on-demand DAST API scans](https://gitlab.com/groups/gitlab-org/-/epics/4254) in GitLab 15.6.
 
 Perform Dynamic Application Security Testing (DAST) of web APIs to help discover bugs and potential
 security issues that other QA processes may miss. Use DAST API tests in addition to
-[GitLab Secure](../index.md)'s other security scanners and your own test processes. You can run DAST
+other [GitLab Secure](../index.md) security scanners and your own test processes. You can run DAST
 API tests either as part your CI/CD workflow, [on-demand](../dast/proxy-based.md#on-demand-scans), or both.
 
 WARNING:
diff --git a/doc/user/product_analytics/index.md b/doc/user/product_analytics/index.md
index 46f8b57a64c..de4e9c3d36c 100644
--- a/doc/user/product_analytics/index.md
+++ b/doc/user/product_analytics/index.md
@@ -6,7 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Product analytics **(ULTIMATE)**
 
-> Introduced in GitLab 15.4 as an [Alpha](../../policy/alpha-beta-support.md#alpha-features) feature [with a flag](../../administration/feature_flags.md) named `cube_api_proxy`. Disabled by default.
+> - Introduced in GitLab 15.4 as an [Alpha](../../policy/alpha-beta-support.md#alpha-features) feature [with a flag](../../administration/feature_flags.md) named `cube_api_proxy`. Disabled by default.
+> - `cube_api_proxy` revised to only reference the [Product Analytics API](../../api/product_analytics.md) in GitLab 15.6.
 
 FLAG:
 On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `cube_api_proxy`.
@@ -16,8 +17,45 @@ This feature is not ready for production use.
 This page is a work in progress, and we're updating the information as we add more features.
 For more information, visit the [Product Analytics group direction page](https://about.gitlab.com/direction/analytics/product-analytics/).
 
+## How Product Analytics works
+
+```mermaid
+---
+title: Product Analytics flow
+---
+flowchart TB
+    subgraph Adding data
+        A([SDK]) --Send user data--> B[Analytics Proxy]
+        B --Transform data and pass it through--> C[Jitsu]
+        C --Pass the data to the associated database--> D([Clickhouse])
+    end
+    subgraph Showing dashboards
+        E([Dashboards]) --Generated from the YAML definition--> F[Dashboard]
+        F --Request data--> G[Product Analytics API]
+        G --Run Cube queries with pre-aggregations--> H[Cube.js]
+        H --Get data from database--> D
+        D --Return results--> H
+        H --> G
+        G --Transform data to be rendered--> F
+    end
+```
+
+Product Analytics uses several tools:
+
+- [**Jitsu**](https://jitsu.com/docs) - A web and app event collection platform that provides a consistent API to collect user data and pass it through to Clickhouse.
+- [**Clickhouse**](https://clickhouse.com/docs) - A database suited to store, query, and retrieve analytical data.
+- [**Cube.js**](https://cube.dev/docs/) - An analytical graphing library that provides an API to run queries against the data stored in Clickhouse.
+
 ## Enable product analytics
 
+> - Introduced in GitLab 15.6 behind the [feature flag](../../administration/feature_flags.md) named `cube_api_proxy`. Disabled by default.
+> - Moved to be behind the [feature flag](../../administration/feature_flags.md) named `product_analytics_admin_settings` in GitLab 15.7. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `cube_api_proxy`.
+On GitLab.com, this feature is not available.
+This feature is not ready for production use.
+
 You can enable and configure product analytics to track events
 within your project applications on a self-managed instance.
 
@@ -45,6 +83,13 @@ Prerequisite:
 
 ## Product analytics dashboards
 
+> Introduced in GitLab 15.5 behind the [feature flag](../../administration/feature_flags.md) named `product_analytics_internal_preview`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `cube_api_proxy`.
+On GitLab.com, this feature is not available.
+This feature is not ready for production use.
+
 Each project can define an unlimited number of dashboards. These dashboards are defined using our YAML schema and stored
 in the `.gitlab/product_analytics/dashboards/` directory of a project repository. The name of the file is the name of the dashboard, and visualizations are shared across dashboards.
 
diff --git a/doc/user/public_access.md b/doc/user/public_access.md
index 773c14c9ec8..2a9a9fb84fe 100644
--- a/doc/user/public_access.md
+++ b/doc/user/public_access.md
@@ -7,63 +7,49 @@ type: reference
 
 # Project and group visibility **(FREE)**
 
-If you have the Owner role, you can set a project's or group's visibility as:
+A project in GitLab can be private, internal, or public.
 
-- **Public**
-- **[Internal](#internal-projects-and-groups)**
-- **Private**
-
-These visibility levels affect who can see the project in the public access directory
-(for example, <https://gitlab.com/public>).
-
-For more granular control, you can determine
-[which features in a project are visible](project/working_with_projects.md#change-the-visibility-of-individual-features-in-a-project).
-
-The visibility setting of a project must be at least as restrictive
-as the visibility of its parent group.
-For example, a private group can include only private projects,
-while a public group can include private, internal, and public projects.
-
-## Public projects and groups
-
-Public projects can be cloned **without any** authentication over HTTPS.
+## Private projects and groups
 
-They are listed in the public access directory (`/public`) for all users.
+For private projects, only project members can:
 
-Public groups can have public, internal, or private subgroups.
+- Clone the project.
+- View the public access directory (`/public`).
 
-**Any authenticated user** has the Guest role on the repository.
+Users with the Guest role cannot clone the project.
 
-NOTE:
-By default, `/public` is visible to unauthenticated users. However, if the
-[**Public** visibility level](admin_area/settings/visibility_and_access_controls.md#restrict-visibility-levels)
-is restricted, `/public` is visible only to authenticated users.
+Private groups can have private subgroups only.
 
 ## Internal projects and groups **(FREE SELF)**
 
-Internal projects can be cloned by any authenticated user except
-[external users](admin_area/external_users.md).
+For internal projects, **any authenticated user**, including users with the Guest role, can:
 
-They are also listed in the public access directory (`/public`), but only for authenticated users.
+- Clone the project.
+- View the public access directory (`/public`).
 
-Internal groups can have internal or private subgroups.
+[External users](admin_area/external_users.md) cannot clone the project.
 
-Any signed-in users except [external users](admin_area/external_users.md) have the
-Guest role on the repository.
+Internal groups can have internal or private subgroups.
 
 NOTE:
 From July 2019, the `Internal` visibility setting is disabled for new projects, groups,
 and snippets on GitLab.com. Existing projects, groups, and snippets using the `Internal`
-visibility setting keep this setting. You can read more about the change in the
-[relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/12388).
+visibility setting keep this setting. For more information, see
+[issue 12388](https://gitlab.com/gitlab-org/gitlab/-/issues/12388).
 
-## Private projects and groups
+## Public projects and groups
 
-Private projects can only be cloned and viewed by project members (except for guests).
+For public projects, **users who are not authenticated**, including users with the Guest role, can:
 
-They appear in the public access directory (`/public`) for project members only.
+- Clone the project.
+- View the public access directory (`/public`).
 
-Private groups can only have private subgroups.
+Public groups can have public, internal, or private subgroups.
+
+NOTE:
+If an administrator restricts the
+[**Public** visibility level](admin_area/settings/visibility_and_access_controls.md#restrict-visibility-levels),
+then `/public` is visible only to authenticated users.
 
 ## Change project visibility
 
@@ -77,6 +63,8 @@ Prerequisite:
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
 1. Change **Project visibility** to either **Private**, **Internal**, or **Public**.
+   The visibility setting for a project must be at least as restrictive
+   as the visibility of its parent group.
 1. Select **Save changes**.
 
 ## Change group visibility
@@ -94,15 +82,21 @@ Prerequisites:
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Naming, visibility**.
 1. Under **Visibility level** select either **Private**, **Internal**, or **Public**.
+   The visibility setting for a project must be at least as restrictive
+   as the visibility of its parent group.
 1. Select **Save changes**.
 
 ## Restrict use of public or internal projects **(FREE SELF)**
 
-You can restrict the use of visibility levels for users when they create a project or a snippet.
-This is useful to prevent users from publicly exposing their repositories by accident. The
-restricted visibility settings do not apply to administrators.
+Administrators can restrict which visibility levels users can choose when they create a project or a snippet.
+This setting can help prevent users from publicly exposing their repositories by accident.
+
+For more information, see [Restrict visibility levels](admin_area/settings/visibility_and_access_controls.md#restrict-visibility-levels).
+
+## Related topics
 
-For details, see [Restricted visibility levels](admin_area/settings/visibility_and_access_controls.md#restrict-visibility-levels).
+- For more granular control of project features, you can
+  [change the visibility of features](project/working_with_projects.md#change-the-visibility-of-individual-features-in-a-project).
 
 <!-- ## Troubleshooting