Add latest changes from gitlab-org/gitlab@master

2 files changed, 16 insertions, 16 deletions

diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index a63d4a98fa2..baa8f11240f 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -10,12 +10,12 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 You can organize GitLab [groups](../index.md) into subgroups. You can use subgroups to:
 
-- Separate internal and external organizations. Because every subgroup can have its own
+- Separate internal and external content. Because every subgroup can have its own
   [visibility level](../../public_access.md), you can host groups for different
   purposes under the same parent group.
-- Organize large projects. You can use subgroups to give different access to parts of
+- Organize large projects. You can use subgroups to manage who can access parts of
   the source code.
-- Manage people and control visibility. Give a user a different
+- Manage permissions. Give a user a different
   [role](../../permissions.md#group-members-permissions) for each group they're [a member of](#subgroup-membership).
 
 Subgroups can:
@@ -25,7 +25,7 @@ Subgroups can:
 - Be nested up to 20 levels.
 - Use [runners](../../../ci/runners/index.md) registered to parent groups:
   - Secrets configured for the parent group are available to subgroup jobs.
-  - Users with the Maintainer role in projects that belong to subgroups can see the details of runners registered to
+  - Users with at least the Maintainer role in projects that belong to subgroups can see the details of runners registered to
     parent groups.
 
 For example:
@@ -117,7 +117,7 @@ For more information, view the [permissions table](../../permissions.md#group-me
 ## Subgroup membership
 
 When you add a member to a group, that member is also added to all subgroups of that group.
-The member's permissions are inherited from the group's parent.
+The member's permissions are inherited from the group into all subgroups.
 
 Subgroup members can be:
 
@@ -189,8 +189,8 @@ Members can be [filtered by inherited or direct membership](../index.md#filter-a
 
 Users with the Owner role in a subgroup can add members to it.
 
-You can't give a user a role in a subgroup that is lower than the roles the user has in ancestor groups.
-To override a user's role in an ancestor group, add the user to the subgroup again with a higher role.
+You can't give a user a role in a subgroup that is lower than the roles the user has in parent groups.
+To override a user's role in a parent group, add the user to the subgroup again with a higher role.
 For example:
 
 - If User 1 is added to group _Two_ with the Developer role, User 1 inherits that role in every subgroup of group _Two_.
@@ -201,7 +201,7 @@ For example:
 
 ## Mention subgroups
 
-Mentioning subgroups ([`@<subgroup_name>`](../../discussions/index.md#mentions)) in issues, commits, and merge requests
+Mentioning subgroups ([`@<subgroup_name>`](../../discussions/index.md#mentions)) in epics, issues, commits, and merge requests
 notifies all direct members of that group. Inherited members of a subgroup are not notified by mentions.
 Mentioning works the same as for projects and groups, and you can choose the group of members to be notified.
 
diff --git a/doc/user/project/pages/getting_started/pages_from_scratch.md b/doc/user/project/pages/getting_started/pages_from_scratch.md
index 9de2703b82b..0695cc20ccd 100644
--- a/doc/user/project/pages/getting_started/pages_from_scratch.md
+++ b/doc/user/project/pages/getting_started/pages_from_scratch.md
@@ -70,7 +70,7 @@ This specific Ruby image is maintained on [DockerHub](https://hub.docker.com/_/r
 Edit your `.gitlab-ci.yml` file and add this text as the first line:
 
 ```yaml
-image: ruby:2.7
+image: ruby:3.2
 ```
 
 If your SSG needs [NodeJS](https://nodejs.org/) to build, you must specify an
@@ -156,7 +156,7 @@ pages:
 Your `.gitlab-ci.yml` file should now look like this:
 
 ```yaml
-image: ruby:2.7
+image: ruby:3.2
 
 pages:
   script:
@@ -198,7 +198,7 @@ First, add a `workflow` section to force the pipeline to run only when changes a
 pushed to branches:
 
 ```yaml
-image: ruby:2.7
+image: ruby:3.2
 
 workflow:
   rules:
@@ -218,7 +218,7 @@ Then configure the pipeline to run the job for the
 [default branch](../../repository/branches/default.md) (here, `main`) only.
 
 ```yaml
-image: ruby:2.7
+image: ruby:3.2
 
 workflow:
   rules:
@@ -249,7 +249,7 @@ To specify a stage for your job to run in,
 add a `stage` line to your CI file:
 
 ```yaml
-image: ruby:2.7
+image: ruby:3.2
 
 workflow:
   rules:
@@ -273,7 +273,7 @@ Now add another job to the CI file, telling it to
 test every push to every branch **except** the `main` branch:
 
 ```yaml
-image: ruby:2.7
+image: ruby:3.2
 
 workflow:
   rules:
@@ -325,7 +325,7 @@ for both jobs, `pages` and `test`.
 Move these commands to a `before_script` section:
 
 ```yaml
-image: ruby:2.7
+image: ruby:3.2
 
 workflow:
   rules:
@@ -366,7 +366,7 @@ This example caches Jekyll dependencies in a `vendor` directory
 when you run `bundle install`:
 
 ```yaml
-image: ruby:2.7
+image: ruby:3.2
 
 workflow:
   rules: