Add latest changes from gitlab-org/gitlab@master

10 files changed, 112 insertions, 98 deletions

diff --git a/doc/administration/index.md b/doc/administration/index.md
index fcda1c4b413..4b98999fb6d 100644
--- a/doc/administration/index.md
+++ b/doc/administration/index.md
@@ -9,12 +9,10 @@ description: 'Learn how to install, configure, update, and maintain your GitLab
 
 Learn how to administer a self-managed GitLab instance.
 
-- [Get started](../administration/get_started.md)
-- [All feature flags](../user/feature_flags.md)
-- [Configure your installation](../administration/configure.md)
-- [Configure GitLab Dedicated](../administration/dedicated/index.md)
-- [Maintain your installation](../administration/operations/index.md)
-- [Secure your installation](../security/index.md)
-- [Administer users](../user/profile/account/create_accounts.md)
+| | | |
+|--|--|--|
+| [**Get started**](../administration/get_started.md) **{chevron-right}**<br><br>Administration overview. | [**All feature flags**](../user/feature_flags.md) **{chevron-right}**<br><br>Complete list of flags. | [**Authentication and authorization**](../administration/auth/index.md) **{chevron-right}**<br><br>Third-party authentication providers. |
+| [**Configure your installation**](../administration/configure.md) **{chevron-right}**<br><br>Installation settings. | [**Update your Admin Area settings**](../administration/settings/index.md) **{chevron-right}**<br><br>Product settings. | [**Configure GitLab Dedicated**](../administration/dedicated/index.md) **{chevron-right}**<br><br>IP allowlists, SAML, maintenance. |
+| [**Maintain your installation**](../administration/operations/index.md) **{chevron-right}**<br><br>Backup and restore, move repos, maintenance tasks. | [**Secure your application**](../user/application_security/secure_your_application.md) **{chevron-right}**<br><br>SSH key limits, 2FA, tokens, hardening. | [**Administer users**](../user/profile/account/create_accounts.md) **{chevron-right}**<br><br>Passwords, user moderation, broadcast messages. |
 
 Only GitLab team members have access to administration tools and settings on GitLab.com.
diff --git a/doc/architecture/blueprints/permissions/index.md b/doc/architecture/blueprints/permissions/index.md
index c131c372550..ced320f5257 100644
--- a/doc/architecture/blueprints/permissions/index.md
+++ b/doc/architecture/blueprints/permissions/index.md
@@ -17,7 +17,7 @@ static [role-based access control system](../../../user/permissions.md#roles).
 
 In %15.9, we [announced](https://about.gitlab.com/blog/2023/03/08/expanding-guest-capabilities-in-gitlab-ultimate/)
 a customer MVC of the custom roles feature. The MVC introduced the ability to
-add one single permission (`read_code`) to a custom role based on a standard
+add one single permission (`read_code`) to a custom role based on a default
 GitLab Guest role. The MVC was [implemented](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106256) by
 taking an existing permission from the GitLab authorization framework and
 enabling it if a custom role has it set to `true`.
@@ -42,7 +42,7 @@ a path for addressing them.
 
 ## What are custom roles?
 
-Our permissions system supports 6 pre-defined roles (Guest, Reporter, Developer, Maintainer, Owner) and users are assigned to per project or group, they can't be modified. Custom roles should solve the problem that our current system is static.
+Our permissions system supports six default roles (Guest, Reporter, Developer, Maintainer, Owner) and users are assigned to per project or group, they can't be modified. Custom roles should solve the problem that our current system is static.
 
 With custom roles, customers can define their own roles and give them permissions they want to. For every role they create they can assign set of permissions. For example, a newly created role "Engineer" could have `read code` and `admin merge requests` enabled but abilities such as `admin issues` disabled.
 
@@ -139,7 +139,7 @@ Cons:
 - Maintaining 2 systems
 - Each new "regular" permission added needs a parallel addition to the
   custom roles system. This makes it difficult to have feature parity between
-  custom roles and static roles.
+  custom roles and default roles.
 - Replacing our existing RBAC system with custom roles (an eventual goal of the
   custom roles feature) is more difficult with this approach because it requires
   retiring the legacy permissions system.
@@ -157,16 +157,16 @@ Cons:
   enable granular access.
 - Each new "regular" permission added needs a parallel addition to the
   bundled permissions for custom roles. This makes it difficult to have feature
-  parity between custom roles and static roles.
+  parity between custom roles and default roles.
 
 ## Glossary
 
 - **RBAC**: Role-based access control; "a method of restricting network access based
   on the roles of individual users." RBAC is the method of access control that
   GitLab uses.
-- **Static roles**: the 5 categories that GitLab users can be grouped into: Guest,
+- **Default roles**: the 5 categories that GitLab users can be grouped into: Guest,
   Reporter, Developer, Maintainer, Owner ([documentation](../../../user/permissions.md#roles)).
-  A static role can be thought of as a group of permissions.
+  A default role can be thought of as a group of permissions.
 - **Declarative Policy**: [code library](https://gitlab.com/gitlab-org/ruby/gems/declarative-policy/)
   used by GitLab to define our authorization logic.
 - **Permissions**: a specific ability that a user with a Role has. For example, a
@@ -175,7 +175,7 @@ Cons:
   represents a "permission" but these may not have a 1:1 mapping with a Declarative Policy
   [ability](https://gitlab.com/gitlab-org/ruby/gems/declarative-policy/-/blob/main/doc/defining-policies.md#invocation).
   An ability is how permissions are represented in the GitLab codebase.
-- **Access level**: integer value representing a static role, used for determining access and calculating inherited user access in group hierarchies ([documentation](../../../api/access_requests.md#valid-access-levels)).
+- **Access level**: integer value representing a default role, used for determining access and calculating inherited user access in group hierarchies ([documentation](../../../api/access_requests.md#valid-access-levels)).
 
 ## Resources
 
diff --git a/doc/ci/runners/index.md b/doc/ci/runners/index.md
index bfb30a36be2..7fb7db3d829 100644
--- a/doc/ci/runners/index.md
+++ b/doc/ci/runners/index.md
@@ -38,6 +38,12 @@ When you use SaaS runners:
 NOTE:
 Jobs handled by SaaS runners on GitLab.com **time out after 3 hours**, regardless of the timeout configured in a project.
 
+## Release cycle for SaaS runner
+
+We aim to update to the latest version of [GitLab Runner](https://docs.gitlab.com/runner/#gitlab-runner-versions) within a week of its release.
+
+You can find all GitLab Runner breaking changes under [Deprecations and removals](../../update/deprecations.md).
+
 ## Security for SaaS runners
 
 GitLab SaaS runners on Linux and Windows run on Google Compute Platform.
@@ -71,7 +77,7 @@ takes over the task of securely deleting the virtual machine and associated data
 
 ## Supported image lifecycle
 
-For runners on macOS and Windows, you can only run jobs on supported images. You cannot bring your own image. Supported images have the following lifecycle:
+SaaS runners on macOS and Windows can only run jobs on supported images. You cannot bring your own image. Supported images have the following lifecycle:
 
 - Beta
 - Generally Available
@@ -100,33 +106,3 @@ Jobs running on GA images are covered by the defined service-level agreement. Ov
 A maximum of two Generally Available (GA) images are supported at a time. After a new GA image is released,
 the oldest GA image becomes deprecated. A deprecated image is no longer
 updated and is deleted after 3 months in accordance with the [deprecation guidelines](../../development/deprecation_guidelines/index.md).
-
-## Major version changes (breaking)
-
-As GitLab CI/CD and Runner have evolved, certain breaking changes have been necessary.
-
-For GitLab 15.0 and later, all breaking changes are documented on the following page:
-
-- [Deprecations and removals](../../update/deprecations.md)
-
-The breaking changes for GitLab Runner in earlier major version releases are:
-
-- 14.0: No breaking changes.
-- 13.0:
-  - [Remove Backported `os.Expand`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4915).
-  - [Remove Fedora 29 package support](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/16158).
-  - [Remove macOS 32-bit support](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25466).
-  - [Removed `debug/jobs/list?v=1` endpoint](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6361).
-  - [Remove support for array of strings when defining services for Docker executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4922).
-  - [Remove `--docker-services` flag on register command](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6404).
-  - [Remove legacy build directory caching](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4180).
-  - [Remove `FF_USE_LEGACY_VOLUMES_MOUNTING_ORDER` feature flag](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6581).
-  - [Remove support for Windows Server 1803](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6553).
-- 12.0:
-  - [Use `refspec` to clone/fetch Git repository](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4069).
-  - [Old cache configuration](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4070).
-  - [Old metrics server configuration](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4072).
-  - [Remove `FF_K8S_USE_ENTRYPOINT_OVER_COMMAND`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4073).
-  - [Remove Linux distributions that reach EOL](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1130).
-  - [Update command line API for helper images](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4013).
-  - [Remove old `git clean` flow](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4175).
diff --git a/doc/ci/runners/saas/macos_saas_runner.md b/doc/ci/runners/saas/macos_saas_runner.md
index 0251c523864..d48e542699e 100644
--- a/doc/ci/runners/saas/macos_saas_runner.md
+++ b/doc/ci/runners/saas/macos_saas_runner.md
@@ -45,14 +45,12 @@ If no image is specified, the macOS runner uses `macos-13-xcode-14`.
 
 ## Image update policy for macOS
 
-macOS and Xcode follow a yearly release cadence, during which GitLab increments its versions synchronously. GitLab typically supports multiple versions of preinstalled tools. For more information, see the [full list of preinstalled software](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/job-images/-/tree/main/toolchain).
+The images and installed components are updated with each GitLab release, to keep the preinstalled software up-to-date. GitLab typically supports multiple versions of preinstalled software. For more information, see the [full list of preinstalled software](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/job-images/-/tree/main/toolchain).
 
-When Apple releases a new macOS version, GitLab releases a new `stable` image based on the OS in the next release,
-which is in Beta.
+Major and minor releases of macOS and Xcode, are made available within two weeks of Apple's release.
 
-With the release of the first patch to macOS, the `stable` image becomes Generally Available (GA). As only two GA images are supported at a time, the prior OS version becomes deprecated and is deleted after three months in accordance with the [supported image lifecycle](../index.md#supported-image-lifecycle).
-
-The `stable` images and installed components are updated every release, to keep the preinstalled software up-to-date.
+A new major release image is initially made available as Beta, and becomes Generally Available (GA) with the release of the first minor release.
+Because only two GA images are supported at a time, the oldest image becomes deprecated and will be removed after three months according to the [supported image lifecycle](../index.md#supported-image-lifecycle).
 
 ## Example `.gitlab-ci.yml` file
 
diff --git a/doc/ci/runners/saas/windows_saas_runner.md b/doc/ci/runners/saas/windows_saas_runner.md
index fd1d5ba1ab7..8fd502e8a3d 100644
--- a/doc/ci/runners/saas/windows_saas_runner.md
+++ b/doc/ci/runners/saas/windows_saas_runner.md
@@ -10,8 +10,7 @@ SaaS runner on Windows autoscale by launching virtual machines on
 the Google Cloud Platform. This solution uses an
 [autoscaling driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/blob/main/docs/README.md)
 developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
-
-These SaaS runners are in [Beta](../../../policy/experiment-beta-support.md#beta)
+SaaS runners on Windows are in [Beta](../../../policy/experiment-beta-support.md#beta)
 and aren't recommended for production workloads.
 
 We want to keep iterating to get Windows runners in a stable state and
@@ -21,27 +20,27 @@ You can follow our work towards this goal in the
 
 ## Machine types available for Windows
 
-| Runner Tag             | vCPUs | Memory | Storage |
-| ---------------------- | ----- | ------ | ------- |
-| `shared-windows`       | 2     | 7.5 GB | 75 GB   |
+| Runner Tag                  | vCPUs | Memory | Storage |
+| --------------------------- | ----- | ------ | ------- |
+| `saas-windows-medium-amd64` | 2     | 7.5 GB | 75 GB   |
 
 ## Supported Windows versions
 
 The Windows runner virtual machine instances do not use the GitLab Docker executor. This means that you can't specify
 [`image`](../../../ci/yaml/index.md#image) or [`services`](../../../ci/yaml/index.md#services) in your pipeline configuration.
-Instead you have to select the [`tags`](../../../ci/yaml/index.md#tags) for the desired Windows version.
 
 You can execute your job in one of the following Windows versions:
 
-| Version tag    | Status        |
-|----------------|---------------|
-| `windows-1809` | `Beta`        |
+| Version      | Status        |
+|--------------|---------------|
+| Windows 2022 | `Beta`        |
+| Windows 2019 | `Deprecated` (Removal in 17.0) |
 
 You can find a full list of available pre-installed software in
 the [pre-installed software documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/main/cookbooks/preinstalled-software/README.md).
 
 NOTE:
-Each time you run a job that requires tooling or dependencies not available in the base image, those components must be installed to the newly provisioned VM increasing the total job duration.
+We are only supporting a single version of Windows at this time.
 
 ## Supported shell
 
@@ -53,29 +52,24 @@ The `script` section of your `.gitlab-ci.yml` file therefore requires PowerShell
 Below is a sample `.gitlab-ci.yml` file that shows how to start using the runners for Windows:
 
 ```yaml
-.shared_windows_runners:
+.windows_job:
   tags:
-    - shared-windows
-    - windows-1809
+    - saas-windows-medium-amd64
   before_script:
     - Set-Variable -Name "time" -Value (date -Format "%H:%m")
     - echo ${time}
     - echo "started by ${GITLAB_USER_NAME}"
 
-stages:
-  - build
-  - test
-
 build:
   extends:
-    - .shared_windows_runners
+    - .windows_job
   stage: build
   script:
     - echo "running scripts in the build job"
 
 test:
   extends:
-    - .shared_windows_runners
+    - .windows_job
   stage: test
   script:
     - echo "running scripts in the test job"
diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md
index 2160c01247d..2185d77e056 100644
--- a/doc/development/documentation/styleguide/word_list.md
+++ b/doc/development/documentation/styleguide/word_list.md
@@ -604,6 +604,10 @@ Instead of:
 
 Do not use **e-mail** with a hyphen. When plural, use **emails** or **email messages**. ([Vale](../testing.md#vale) rule: [`SubstitutionSuggestions.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionSuggestions.yml))
 
+## email address
+
+Use **email address** when referring to addresses used in emails. Do not shorten to **email**, which are messages.
+
 ## emoji
 
 Use **emoji** to refer to the plural form of **emoji**.
@@ -984,6 +988,11 @@ Thereafter, use **Issue description generation** by itself.
 
 Use lowercase for **issue weights**.
 
+## IP address
+
+Use **IP address** when refering to addresses used with Internet Protocal (IP). Do not refer to an IP address as an
+**IP**.
+
 ## it
 
 When you use the word **it**, ensure the word it refers to is obvious.
diff --git a/doc/development/permissions/custom_roles.md b/doc/development/permissions/custom_roles.md
index b8f6eba3340..7a0d325d09a 100644
--- a/doc/development/permissions/custom_roles.md
+++ b/doc/development/permissions/custom_roles.md
@@ -15,16 +15,16 @@ In this context, the terms "permission" and "ability" are often used interchange
 - "Ability" is an action a user can do. These map to [Declarative Policy abilities](https://gitlab.com/gitlab-org/ruby/gems/declarative-policy/-/blob/main/doc/defining-policies.md#rules) and live in Policy classes in `ee/app/policies/*`.
 - "Permission" is how we refer to an ability [in user-facing documentation](../../user/permissions.md). The documentation of permissions is manually generated so there is not necessarily a 1:1 mapping of the permissions listed in documentation and the abilities defined in Policy classes.
 
-## Custom roles vs static roles
+## Custom roles vs default roles
 
-In GitLab 15.9 and earlier, GitLab only had [static roles](predefined_roles.md) as a permission system. In this system, there are a few predefined roles that are statically assigned to certain abilities. These static roles are not customizable by customers.
+In GitLab 15.9 and earlier, GitLab only had [default roles](predefined_roles.md) as a permission system. In this system, there are a few predefined roles that are statically assigned to certain abilities. These default roles are not customizable by customers.
 
 With custom roles, the customers can decide which abilities they want to assign to certain user groups. For example:
 
-- In the static role system, reading of vulnerabilities is limited to a Developer role.
-- In the custom role system, a customer can assign this ability to a new custom role based on any static role.
+- In the default role system, reading of vulnerabilities is limited to a Developer role.
+- In the custom role system, a customer can assign this ability to a new custom role based on any default role.
 
-Like static roles, custom roles are [inherited](../../user/project/members/index.md#inherited-membership) within a group hierarchy. If a user has custom role for a group, that user will also have a custom role for any projects or subgroups within the group.
+Like default roles, custom roles are [inherited](../../user/project/members/index.md#inherited-membership) within a group hierarchy. If a user has custom role for a group, that user will also have a custom role for any projects or subgroups within the group.
 
 ## Technical overview
 
@@ -34,7 +34,7 @@ Like static roles, custom roles are [inherited](../../user/project/members/index
 - A Group or project membership can be associated with any custom role that is defined on the root-level group of the group or project.
 - The `member_roles` table includes individual permissions and a `base_access_level` value.
 - The `base_access_level` must be a [valid access level](../../api/access_requests.md#valid-access-levels).
-  The `base_access_level` determines which abilities are included in the custom role. For example, if the `base_access_level` is `10`, the custom role will include any abilities that a static Guest role would receive, plus any additional abilities that are enabled by the `member_roles` record by setting an attribute, such as `read_code`, to true.
+  The `base_access_level` determines which abilities are included in the custom role. For example, if the `base_access_level` is `10`, the custom role will include any abilities that a default Guest role would receive, plus any additional abilities that are enabled by the `member_roles` record by setting an attribute, such as `read_code`, to true.
 - A custom role can enable additional abilities for a `base_access_level` but it cannot disable a permission. As a result, custom roles are "additive only". The rationale for this choice is [in this comment](https://gitlab.com/gitlab-org/gitlab/-/issues/352891#note_1059561579).
 - Custom role abilities are supported at project level and group level.
 
diff --git a/doc/security/index.md b/doc/security/index.md
index ffc436e4286..42681709e93 100644
--- a/doc/security/index.md
+++ b/doc/security/index.md
@@ -7,27 +7,62 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Secure your installation **(FREE ALL)**
 
-- [Passwords and OAuth tokens storage](password_storage.md)
-- [Password length limits](password_length_limits.md)
-- [Generated passwords for users created through integrated authentication](passwords_for_integrated_authentication_methods.md)
-- [Restrict SSH key technologies and minimum length](ssh_keys_restrictions.md)
-- [Rate limits](rate_limits.md)
-- [Filtering outbound requests](webhooks.md)
-- [Information exclusivity](information_exclusivity.md)
-- [Reset user password](reset_user_password.md)
-- [Unlock a locked user](unlock_user.md)
-- [User File Uploads](user_file_uploads.md)
-- [How we manage the CRIME vulnerability](crime_vulnerability.md)
-- [Enforce Two-factor authentication](two_factor_authentication.md)
+## General Information
+
+This section covers some general information and recommendations regarding the platform.
+
+- [How passwords and OAuth tokens are stored](password_storage.md).
+- [How passwords for users created through integrated authentication are generated](passwords_for_integrated_authentication_methods.md).
+- [How we manage the CRIME vulnerability](crime_vulnerability.md).
+- [Secrets for third-party integrations should be rotated regularly](rotate_integrations_secrets.md).
+
+## Recommendations
+
+The [Hardening Guide](hardening.md) contains additional general recommendations that can be implemented for hardening an install.
+
+### User Accounts
+
+- [Review authentication options](../administration/auth/index.md).
+- [Configure password length limits](password_length_limits.md).
+- [Restrict SSH key technologies and require minimum key lengths](ssh_keys_restrictions.md).
+- [Restrict account creation with sign up restrictions](../administration/settings/sign_up_restrictions.md).
 - [Send email confirmation on sign-up](user_email_confirmation.md)
-- [Security of running jobs](https://docs.gitlab.com/runner/security/)
-- [Proxying images](asset_proxy.md)
-- [CI/CD variables](../ci/variables/index.md#cicd-variable-security)
-- [Token overview](token_overview.md)
-- [Rotate secrets of third-party integrations](rotate_integrations_secrets.md)
-- [Maximum decompressed file size for imported archives](../administration/settings/import_and_export_settings.md#maximum-decompressed-file-size-for-imported-archives)
-- [Responding to security incidents](responding_to_security_incidents.md)
+- [Enforce two-factor authentication](two_factor_authentication.md) to require users to [enable two-factor authentication](../user/profile/account/two_factor_authentication.md).
+- [Restrict logins from multiple IPs](../administration/reporting/ip_addr_restrictions.md).
+- [How to reset a user password](reset_user_password.md).
+- [How to unlock a locked user](unlock_user.md).
+
+### Data Access
+
+- [Information exclusivity](information_exclusivity.md).
+- [Protecting and removing user file uploads](user_file_uploads.md).
+- [Proxying linked images for user privacy](asset_proxy.md).
 
-To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../administration/settings/sign_up_restrictions.md) and [Authentication options](../administration/auth/index.md). For more detailed information, refer to [Hardening](hardening.md).
+### Platform Usage & Settings
+
+- [Review GitLab token type and usages](token_overview.md).
+- [How to configure rate limits improve security and availability](rate_limits.md).
+- [How to filter outbound webhook requests](webhooks.md).
+- [How to configure import and export limits and timeouts](../administration/settings/import_and_export_settings.md).
+- [Review Runner security considerations and recommendations](https://docs.gitlab.com/runner/security/).
+- [Review CI/CD variables security considerations](../ci/variables/index.md#cicd-variable-security).
+- [Review pipeline security for usage and protection of secrets in CI/CD Pipelines](../ci/pipelines/pipeline_security.md).
+
+### Patching
 
 Self-managed GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance.
+
+## Monitoring
+
+### Logs
+
+- [Review the log types and contents produced by GitLab](../administration/logs/index.md).
+- [Review Runner job logs information](../administration/job_logs.md).
+- [How to use correlation ID to trace logs](../administration/logs/tracing_correlation_id.md).
+- [Logging configuration and access](https://docs.gitlab.com/omnibus/settings/logs.html).
+- [How to configure Audit Event Streaming](../administration/audit_event_streaming/index.md).
+- [Providing assistance to GitLab.com customers during customer-based security incidents](https://handbook.gitlab.com/handbook/security/customer-requests/#conditions-and-requirements).
+
+## Response
+
+- [Responding to security incidents](responding_to_security_incidents.md).
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 84e9533f725..36e1ae1e0c8 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -16,10 +16,11 @@ GitLab [administrators](../administration/index.md) have all permissions.
 
 ## Roles
 
-The available roles are:
+You can assign users a default role or a [custom role](custom_roles.md).
+
+The available default roles are:
 
 - Guest (This role applies to [private and internal projects](../user/public_access.md) only.)
-- [Custom](custom_roles.md)
 - Reporter
 - Developer
 - Maintainer
diff --git a/doc/user/project/repository/branches/index.md b/doc/user/project/repository/branches/index.md
index d6bcae57322..5efa834d74a 100644
--- a/doc/user/project/repository/branches/index.md
+++ b/doc/user/project/repository/branches/index.md
@@ -121,6 +121,9 @@ To view and manage your branches in the GitLab user interface:
 On this page, you can:
 
 - See all branches, or filter to see only active or stale branches.
+
+  A branch is considered active if a commit has been made to it in the last three months.
+  Otherwise it is considered stale.
 - Create new branches.
 - [Compare branches](#compare-branches).
 - Delete merged branches.