diff --git a/app/models/user.rb b/app/models/user.rb
index 032ad26455c..db62211444c 100644
--- a/app/models/user.rb
+++ b/app/models/user.rb
@@ -1245,7 +1245,7 @@ class User < ApplicationRecord
   end
 
   def solo_owned_groups
-    @solo_owned_groups ||= owned_groups.select do |group|
+    @solo_owned_groups ||= owned_groups.includes(:owners).select do |group|
       group.owners == [self]
     end
   end
diff --git a/changelogs/unreleased/cat-fix-nplus1-solo-owned-groups.yml b/changelogs/unreleased/cat-fix-nplus1-solo-owned-groups.yml
new file mode 100644
index 00000000000..f438bb2f829
--- /dev/null
+++ b/changelogs/unreleased/cat-fix-nplus1-solo-owned-groups.yml
@@ -0,0 +1,5 @@
+---
+title: Fix N+1 when looking up user's solo owned groups
+merge_request: 48340
+author:
+type: performance
diff --git a/doc/ci/multi_project_pipelines.md b/doc/ci/multi_project_pipelines.md
index c06eea20f6c..aa8e196ac0e 100644
--- a/doc/ci/multi_project_pipelines.md
+++ b/doc/ci/multi_project_pipelines.md
@@ -301,6 +301,7 @@ Some features are not implemented yet. For example, support for environments.
 - `only` and `except`
 - `when` (only with `on_success`, `on_failure`, and `always` values)
 - `extends`
+- `needs`
 
 ## Trigger a pipeline when an upstream project is rebuilt **(PREMIUM)**
 
diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md
index 41fcf5301ad..060318b209e 100644
--- a/doc/development/application_limits.md
+++ b/doc/development/application_limits.md
@@ -12,7 +12,7 @@ limits to GitLab.
 ## Documentation
 
 First of all, you have to gather information and decide which are the different
-limits that will be set for the different GitLab tiers. You also need to
+limits that are set for the different GitLab tiers. You also need to
 coordinate with others to [document](../administration/instance_limits.md)
 and communicate those limits.
 
@@ -63,7 +63,7 @@ It's recommended to create two separate migration script files.
    end
    ```
 
-   Some plans exist only on GitLab.com. This will be a no-op for plans
+   Some plans exist only on GitLab.com. This is a no-op for plans
    that do not exist.
 
 ### Plan limits validation
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 970ceeef006..9bf0adf5b37 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -282,8 +282,8 @@ When deployed, GitLab should be considered the amalgamation of the below process
 
 GitLab can be considered to have two layers from a process perspective:
 
-- **Monitoring**: Anything from this layer is not required to deliver GitLab the application, but will allow administrators more insight into their infrastructure and what the service as a whole is doing.
-- **Core**: Any process that is vital for the delivery of GitLab as a platform. If any of these processes halt there will be a GitLab outage. For the Core layer, you can further divide into:
+- **Monitoring**: Anything from this layer is not required to deliver GitLab the application, but allows administrators more insight into their infrastructure and what the service as a whole is doing.
+- **Core**: Any process that is vital for the delivery of GitLab as a platform. If any of these processes halt, a GitLab outage results. For the Core layer, you can further divide into:
   - **Processors**: These processes are responsible for actually performing operations and presenting the service.
   - **Data**: These services store/expose structured data for the GitLab service.
 
@@ -297,7 +297,7 @@ GitLab can be considered to have two layers from a process perspective:
 - Process: `alertmanager`
 - GitLab.com: [Monitoring of GitLab.com](https://about.gitlab.com/handbook/engineering/monitoring/)
 
-[Alert manager](https://prometheus.io/docs/alerting/latest/alertmanager/) is a tool provided by Prometheus that _"handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or Opsgenie. It also takes care of silencing and inhibition of alerts."_ You can read more in [issue #45740](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45740) about what we will be alerting on.
+[Alert manager](https://prometheus.io/docs/alerting/latest/alertmanager/) is a tool provided by Prometheus that _"handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or Opsgenie. It also takes care of silencing and inhibition of alerts."_ You can read more in [issue #45740](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45740) about what we alert on.
 
 #### Certificate management
 
@@ -600,7 +600,7 @@ GitLab packages the popular Database to provide storage for Application meta dat
 - Process: `postgres-exporter`
 - GitLab.com: [Monitoring of GitLab.com](https://about.gitlab.com/handbook/engineering/monitoring/)
 
-[`postgres_exporter`](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that will deliver data about PostgreSQL to Prometheus for use in Grafana Dashboards.
+[`postgres_exporter`](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that delivers data about PostgreSQL to Prometheus for use in Grafana Dashboards.
 
 #### Prometheus
 
@@ -656,10 +656,10 @@ Redis is packaged to provide a place to store:
 
 The registry is what users use to store their own Docker images. The bundled
 registry uses NGINX as a load balancer and GitLab as an authentication manager.
-Whenever a client requests to pull or push an image from the registry, it will
-return a `401` response along with a header detailing where to get an
-authentication token, in this case the GitLab instance. The client will then
-request a pull or push auth token from GitLab and retry the original request
+Whenever a client requests to pull or push an image from the registry, it
+returns a `401` response along with a header detailing where to get an
+authentication token, in this case the GitLab instance. The client then
+requests a pull or push auth token from GitLab and retries the original request
 to the registry. Learn more about [token authentication](https://docs.docker.com/registry/spec/auth/token/).
 
 An external registry can also be configured to use GitLab as an auth endpoint.
@@ -710,7 +710,7 @@ disabled by default.
 - Process: `puma`
 - GitLab.com: [Puma](../user/gitlab_com/index.md#puma)
 
-[Puma](https://puma.io/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often process output you will see this as `bundle` or `config.ru` depending on the GitLab version.
+[Puma](https://puma.io/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often this displays in process output as `bundle` or `config.ru` depending on the GitLab version.
 
 #### Unicorn
 
@@ -727,7 +727,7 @@ disabled by default.
 - Process: `unicorn`
 - GitLab.com: [Unicorn](../user/gitlab_com/index.md#unicorn)
 
-[Unicorn](https://yhbt.net/unicorn/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often process output you will see this as `bundle` or `config.ru` depending on the GitLab version.
+[Unicorn](https://yhbt.net/unicorn/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often this displays in process output as `bundle` or `config.ru` depending on the GitLab version.
 
 #### LDAP Authentication
 
@@ -792,16 +792,16 @@ It's important to understand the distinction as some processes are used in both
 
 ### GitLab Web HTTP request cycle
 
-When making a request to an HTTP Endpoint (think `/users/sign_in`) the request will take the following path through the GitLab Service:
+When making a request to an HTTP Endpoint (think `/users/sign_in`) the request takes the following path through the GitLab Service:
 
 - NGINX - Acts as our first line reverse proxy.
 - GitLab Workhorse - This determines if it needs to go to the Rails application or somewhere else to reduce load on Puma.
-- Puma - Since this is a web request, and it needs to access the application it will go to Puma.
+- Puma - Since this is a web request, and it needs to access the application, it routes to Puma.
 - PostgreSQL/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
 
 ### GitLab Git request cycle
 
-Below we describe the different paths that HTTP vs. SSH Git requests will take. There is some overlap with the Web Request Cycle but also some differences.
+Below we describe the different paths that HTTP vs. SSH Git requests take. There is some overlap with the Web Request Cycle but also some differences.
 
 ### Web request (80/443)
 
diff --git a/doc/development/changelog.md b/doc/development/changelog.md
index b8e879c1826..35fadd61d41 100644
--- a/doc/development/changelog.md
+++ b/doc/development/changelog.md
@@ -118,7 +118,7 @@ Its simplest usage is to provide the value for `title`:
 bin/changelog 'Hey DZ, I added a feature to GitLab!'
 ```
 
-If you want to generate a changelog entry for GitLab EE, you will need to pass
+If you want to generate a changelog entry for GitLab EE, you must pass
 the `--ee` option:
 
 ```plaintext
@@ -144,10 +144,10 @@ At this point the script would ask you to select the category of the change (map
 ```
 
 The entry filename is based on the name of the current Git branch. If you run
-the command above on a branch called `feature/hey-dz`, it will generate a
+the command above on a branch called `feature/hey-dz`, it generates a
 `changelogs/unreleased/feature-hey-dz.yml` file.
 
-The command will output the path of the generated file and its contents:
+The command outputs the path of the generated file and its contents:
 
 ```plaintext
 create changelogs/unreleased/my-feature.yml
@@ -175,7 +175,7 @@ type:
 You can pass the **`--amend`** argument to automatically stage the generated
 file and amend it to the previous commit.
 
-If you use **`--amend`** and don't provide a title, it will automatically use
+If you use **`--amend`** and don't provide a title, it uses
 the "subject" of the previous commit, which is the first line of the commit
 message:
 
diff --git a/doc/development/documentation/site_architecture/deployment_process.md b/doc/development/documentation/site_architecture/deployment_process.md
index f101a669968..49295bf8a67 100644
--- a/doc/development/documentation/site_architecture/deployment_process.md
+++ b/doc/development/documentation/site_architecture/deployment_process.md
@@ -36,7 +36,7 @@ and tag all tooling images locally:
    ```
 
 For each image, there's a manual job under the `images` stage in
-[`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/.gitlab-ci.yml) which can be invoked at will.
+[`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/.gitlab-ci.yml) which can be invoked at any time.
 
 ## Update an old Docker image with new upstream docs content
 
@@ -51,7 +51,7 @@ Porting changes to older branches can have unintended effects as we're constantl
 changing the backend of the website. Use only when you know what you're doing
 and make sure to test locally.
 
-The website will keep changing and being improved. In order to consolidate
+The website keeps changing and being improved. In order to consolidate
 those changes to the stable branches, we'd need to pick certain changes
 from time to time.
 
diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md
index 3772746e25b..7d9528e50d6 100644
--- a/doc/development/documentation/site_architecture/index.md
+++ b/doc/development/documentation/site_architecture/index.md
@@ -46,7 +46,7 @@ from where content is sourced, the `gitlab-docs` project, and the published outp
     H -- symlink --> G
 ```
 
-You will not find any GitLab docs content in the `gitlab-docs` repository.
+GitLab docs content isn't kept in the `gitlab-docs` repository.
 All documentation files are hosted in the respective repository of each
 product, and all together are pulled to generate the docs website:
 
@@ -62,7 +62,7 @@ in order not to break any existing links throughout the internet, we still
 maintain the CE docs (`https://docs.gitlab.com/ce/`), although it is hidden
 from the website, and is now a symlink to the EE docs. When
 [Pages supports redirects](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/24),
-we will be able to remove this completely.
+we can remove this completely.
 
 ## Assets
 
@@ -179,7 +179,7 @@ we reference the array with a symbol (`:versions`).
 
 Whenever the custom CSS and JavaScript files under `content/assets/` change,
 make sure to bump their version in the front matter. This method guarantees that
-your changes will take effect by clearing the cache of previous files.
+your changes take effect by clearing the cache of previous files.
 
 Always use Nanoc's way of including those files, do not hardcode them in the
 layouts. For example use:
@@ -196,7 +196,7 @@ The links pointing to the files should be similar to:
 <%= @items['/path/to/assets/file.*'].path %>
 ```
 
-Nanoc will then build and render those links correctly according with what's
+Nanoc then builds and renders those links correctly according with what's
 defined in [`Rules`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/Rules).
 
 ## Linking to source files
@@ -236,7 +236,7 @@ If you’re a GitLab team member, find credentials for the Algolia dashboard
 in the shared [GitLab 1Password account](https://about.gitlab.com/handbook/security/#1password-for-teams).
 To receive weekly reports of the search usage, search the Google doc with
 title `Email, Slack, and GitLab Groups and Aliases`, search for `docsearch`,
-and add a comment with your email. You'll be added to the alias that gets the weekly
+and add a comment with your email to be added to the alias that gets the weekly
 reports.
 
 ## Monthly release process (versions)
diff --git a/doc/development/documentation/site_architecture/release_process.md b/doc/development/documentation/site_architecture/release_process.md
index 547adc89a08..6c130e2e04b 100644
--- a/doc/development/documentation/site_architecture/release_process.md
+++ b/doc/development/documentation/site_architecture/release_process.md
@@ -44,14 +44,14 @@ this needs to happen when the stable branches for all products have been created
    ```
 
     A new `Dockerfile.12.0` should have been created and `.gitlab-ci.yml` should
-    have the branches variables updated into a new branch. They will be automatically
+    have the branches variables updated into a new branch. They are automatically
     committed.
 
 1. Push the newly created branch, but **don't create a merge request**.
-   Once you push, the `image:docker-singe` job will create a new Docker image
+   After you push, the `image:docker-singe` job creates a new Docker image
    tagged with the branch name you created in the first step. In the end, the
-   image will be uploaded in the [Container Registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry)
-   and it will be listed under the `registry` environment folder at
+   image is uploaded in the [Container Registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry)
+   and it is listed under the `registry` environment folder at
    `https://gitlab.com/gitlab-org/gitlab-docs/-/environments/folders/registry` (must
    have developer access).
 
@@ -114,20 +114,20 @@ version and rotates the old one:
 
 The versions dropdown is in a way "hardcoded". When the site is built, it looks
 at the contents of `content/_data/versions.yaml` and based on that, the dropdown
-is populated. So, older branches will have different content, which means the
-dropdown will list one or more releases behind. Remember that the new changes of
+is populated. So, older branches have different content, which means the
+dropdown list one or more releases behind. Remember that the new changes of
 the dropdown are included in the unmerged `release-X-Y` branch.
 
 The content of `content/_data/versions.yaml` needs to change for all online
 versions (stable branches `X.Y` of the `gitlab-docs` project):
 
-1. Run the Rake task that will create all the respective merge requests needed to
-   update the dropdowns and will be set to automatically be merged when their
+1. Run the Rake task that creates all the respective merge requests needed to
+   update the dropdowns and are set to automatically be merged when their
    pipelines succeed:
 
    NOTE: **Note:**
    The `release-X-Y` branch needs to be present locally,
-   and you need to have switched to it, otherwise the Rake task will fail.
+   and you need to have switched to it, otherwise the Rake task fails.
 
    ```shell
    git checkout release-X-Y
@@ -144,7 +144,7 @@ In case a pipeline fails, see [troubleshooting](#troubleshooting).
 ## 5. Merge the release merge request
 
 The dropdown merge requests should have now been merged into their respective
-version (stable `X.Y` branch), which will trigger another pipeline. At this point,
+version (stable `X.Y` branch), which triggers another pipeline. At this point,
 you need to only babysit the pipelines and make sure they don't fail:
 
 1. Check the [pipelines page](https://gitlab.com/gitlab-org/gitlab-docs/pipelines)
@@ -152,9 +152,9 @@ you need to only babysit the pipelines and make sure they don't fail:
 1. After all the pipelines of the online versions succeed, merge the release merge request.
 1. Finally, run the
    [`Build docker images weekly` pipeline](https://gitlab.com/gitlab-org/gitlab-docs/pipeline_schedules)
-   that will build the `:latest` and `:archives` Docker images.
+   that builds the `:latest` and `:archives` Docker images.
 
-Once the scheduled pipeline succeeds, the docs site will be deployed with all
+Once the scheduled pipeline succeeds, the docs site is deployed with all
 new versions online.
 
 ## Troubleshooting
diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md
index 9b2081b2821..0df770e74ad 100644
--- a/doc/development/gitaly.md
+++ b/doc/development/gitaly.md
@@ -191,6 +191,10 @@ If you want to run tests locally against a modified version of Gitaly you
 can replace `tmp/tests/gitaly` with a symlink. This is much faster
 because it avoids a Gitaly re-install each time you run `rspec`.
 
+Make sure this directory contains the files `config.toml` and `praefect.config.toml`.
+You can copy them from `config.toml.example` and `config.praefect.toml.example` respectively.
+After copying, make sure to edit them so everything points to the correct paths.
+
 ```shell
 rm -rf tmp/tests/gitaly
 ln -s /path/to/gitaly tmp/tests/gitaly
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 78acd729b9b..786ce55ea85 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Migration Style Guide
 
 When writing migrations for GitLab, you have to take into account that
-these will be run by hundreds of thousands of organizations of all sizes, some with
+these are run by hundreds of thousands of organizations of all sizes, some with
 many years of data in their database.
 
 In addition, having to take a server offline for an upgrade small or big is a
@@ -44,15 +44,15 @@ and post-deployment migrations (`db/post_migrate`) are run after the deployment
 Changes to the schema should be committed to `db/structure.sql`. This
 file is automatically generated by Rails, so you normally should not
 edit this file by hand. If your migration is adding a column to a
-table, that column will be added at the bottom. Please do not reorder
-columns manually for existing tables as this will cause confusion to
+table, that column is added at the bottom. Please do not reorder
+columns manually for existing tables as this causes confusion to
 other people using `db/structure.sql` generated by Rails.
 
 When your local database in your GDK is diverging from the schema from
 `master` it might be hard to cleanly commit the schema changes to
 Git. In that case you can use the `scripts/regenerate-schema` script to
 regenerate a clean `db/structure.sql` for the migrations you're
-adding. This script will apply all migrations found in `db/migrate`
+adding. This script applies all migrations found in `db/migrate`
 or `db/post_migrate`, so if there are any migrations you don't want to
 commit to the schema, rename or remove them. If your branch is not
 targeting `master` you can set the `TARGET` environment variable.
@@ -80,7 +80,7 @@ and whether they require downtime and how to work around that whenever possible.
 
 Every migration must specify if it requires downtime or not, and if it should
 require downtime it must also specify a reason for this. This is required even
-if 99% of the migrations won't require downtime as this makes it easier to find
+if 99% of the migrations don't require downtime as this makes it easier to find
 the migrations that _do_ require downtime.
 
 To tag a migration, add the following two constants to the migration class'
@@ -104,7 +104,7 @@ class MyMigration < ActiveRecord::Migration[6.0]
 end
 ```
 
-It is an error (that is, CI will fail) if the `DOWNTIME` constant is missing
+It is an error (that is, CI fails) if the `DOWNTIME` constant is missing
 from a migration class.
 
 ## Reversibility
@@ -136,7 +136,7 @@ By default, migrations are single transaction. That is, a transaction is opened
 at the beginning of the migration, and committed after all steps are processed.
 
 Running migrations in a single transaction makes sure that if one of the steps fails,
-none of the steps will be executed, leaving the database in valid state.
+none of the steps are executed, leaving the database in valid state.
 Therefore, either:
 
 - Put all migrations in one single-transaction migration.
@@ -146,12 +146,12 @@ Therefore, either:
 For example, if you create an empty table and need to build an index for it,
 it is recommended to use a regular single-transaction migration and the default
 rails schema statement: [`add_index`](https://api.rubyonrails.org/v5.2/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html#method-i-add_index).
-This is a blocking operation, but it won't cause problems because the table is not yet used,
+This is a blocking operation, but it doesn't cause problems because the table is not yet used,
 and therefore it does not have any records yet.
 
 ## Heavy operations in a single transaction
 
-When using a single-transaction migration, a transaction will hold on a database connection
+When using a single-transaction migration, a transaction holds a database connection
 for the duration of the migration, so you must make sure the actions in the migration
 do not take too much time: GitLab.com’s production database has a `15s` timeout, so
 in general, the cumulative execution time in a migration should aim to fit comfortably
@@ -183,8 +183,8 @@ on the `users` table once it has been enqueued.
 More information about PostgresSQL locks: [Explicit Locking](https://www.postgresql.org/docs/current/explicit-locking.html)
 
 For stability reasons, GitLab.com has a specific [`statement_timeout`](../user/gitlab_com/index.md#postgresql)
-set. When the migration is invoked, any database query will have
-a fixed time to execute. In a worst-case scenario, the request will sit in the
+set. When the migration is invoked, any database query has
+a fixed time to execute. In a worst-case scenario, the request sits in the
 lock queue, blocking other queries for the duration of the configured statement timeout,
 then failing with `canceling statement due to statement timeout` error.
 
@@ -275,7 +275,7 @@ end
 
 **Creating a new table when we have two foreign keys:**
 
-For this, we'll need three migrations:
+For this, we need three migrations:
 
 1. Creating the table without foreign keys (with the indices).
 1. Add foreign key to the first table.
@@ -355,7 +355,7 @@ def up
 end
 ```
 
-The RuboCop rule generally allows standard Rails migration methods, listed below. This example will cause a Rubocop offense:
+The RuboCop rule generally allows standard Rails migration methods, listed below. This example causes a Rubocop offense:
 
 ```ruby
 disable_ddl_transaction!
@@ -400,9 +400,9 @@ In a worst-case scenario, the method:
 
 - Executes the block for a maximum of 50 times over 40 minutes.
   - Most of the time is spent in a pre-configured sleep period after each iteration.
-- After the 50th retry, the block will be executed without `lock_timeout`, just
+- After the 50th retry, the block is executed without `lock_timeout`, just
 like a standard migration invocation.
-- If a lock cannot be acquired, the migration will fail with `statement timeout` error.
+- If a lock cannot be acquired, the migration fails with `statement timeout` error.
 
 The migration might fail if there is a very long running transaction (40+ minutes)
 accessing the `users` table.
@@ -438,9 +438,9 @@ class MyMigration < ActiveRecord::Migration[6.0]
 end
 ```
 
-Here the call to `disable_statement_timeout` will use the connection local to
+Here the call to `disable_statement_timeout` uses the connection local to
 the `with_multiple_threads` block, instead of re-using the global connection
-pool. This ensures each thread has its own connection object, and won't time
+pool. This ensures each thread has its own connection object, and doesn't time
 out when trying to obtain one.
 
 PostgreSQL has a maximum amount of connections that it allows. This
@@ -583,7 +583,7 @@ remember to add an index on the column.
 This is **required** for all foreign-keys, e.g., to support efficient cascading
 deleting: when a lot of rows in a table get deleted, the referenced records need
 to be deleted too. The database has to look for corresponding records in the
-referenced table. Without an index, this will result in a sequential scan on the
+referenced table. Without an index, this results in a sequential scan on the
 table, which can take a long time.
 
 Here's an example where we add a new column with a foreign key
@@ -621,7 +621,7 @@ the standard `add_column` helper should be used in all cases.
 
 Before PostgreSQL 11, adding a column with a default was problematic as it would
 have caused a full table rewrite. The corresponding helper `add_column_with_default`
-has been deprecated and will be removed in a later release.
+has been deprecated and is scheduled to be removed in a later release.
 
 If a backport adding a column with a default value is needed for %12.9 or earlier versions,
 it should use `add_column_with_default` helper. If a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3)
@@ -667,7 +667,7 @@ without requiring `disable_ddl_transaction!`.
 ## Updating an existing column
 
 To update an existing column to a particular value, you can use
-`update_column_in_batches`. This will split the updates into batches, so we
+`update_column_in_batches`. This splits the updates into batches, so we
 don't update too many rows at in a single statement.
 
 This updates the column `foo` in the `projects` table to 10, where `some_column`
@@ -782,12 +782,12 @@ end
 ## Integer column type
 
 By default, an integer column can hold up to a 4-byte (32-bit) number. That is
-a max value of 2,147,483,647. Be aware of this when creating a column that will
-hold file sizes in byte units. If you are tracking file size in bytes, this
+a max value of 2,147,483,647. Be aware of this when creating a column that
+holds file sizes in byte units. If you are tracking file size in bytes, this
 restricts the maximum file size to just over 2GB.
 
 To allow an integer column to hold up to an 8-byte (64-bit) number, explicitly
-set the limit to 8-bytes. This will allow the column to hold a value up to
+set the limit to 8-bytes. This allows the column to hold a value up to
 `9,223,372,036,854,775,807`.
 
 Rails migration example:
@@ -837,7 +837,7 @@ timestamps with timezones:
 - `datetime_with_timezone`
 
 This ensures all timestamps have a time zone specified. This, in turn, means
-existing timestamps won't suddenly use a different timezone when the system's
+existing timestamps don't suddenly use a different timezone when the system's
 timezone changes. It also makes it very clear which timezone was used in the
 first place.
 
@@ -938,19 +938,17 @@ Since we had to do this a few times already, there are now some helpers to help
 with this.
 
 To use this you can include `Gitlab::Database::RenameReservedPathsMigration::V1`
-in your migration. This will provide 3 methods which you can pass one or more
+in your migration. This provides 3 methods which you can pass one or more
 paths that need to be rejected.
 
-**`rename_root_paths`**: This will rename the path of all _namespaces_ with the
+- **`rename_root_paths`**: Renames the path of all _namespaces_ with the
 given name that don't have a `parent_id`.
-
-**`rename_child_paths`**: This will rename the path of all _namespaces_ with the
+- **`rename_child_paths`**: Renames the path of all _namespaces_ with the
 given name that have a `parent_id`.
-
-**`rename_wildcard_paths`**: This will rename the path of all _projects_, and all
+- **`rename_wildcard_paths`**: Renames the path of all _projects_, and all
 _namespaces_ that have a `project_id`.
 
-The `path` column for these rows will be renamed to their previous value followed
+The `path` column for these rows are renamed to their previous value followed
 by an integer. For example: `users` would turn into `users0`
 
 ## Using models in migrations (discouraged)
diff --git a/doc/development/pry_debugging.md b/doc/development/pry_debugging.md
index 7f9a49d4d50..eac84a3f13d 100644
--- a/doc/development/pry_debugging.md
+++ b/doc/development/pry_debugging.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ## Invoking pry debugging
 
 To invoke the debugger, place `binding.pry` somewhere in your
-code. When the Ruby interpreter hits that code, execution will stop,
+code. When the Ruby interpreter hits that code, execution stops,
 and you can type in commands to debug the state of the program
 
 ## `byebug` vs `binding.pry`
@@ -20,7 +20,7 @@ use the powerful Pry REPL.
 `binding.pry` uses Pry, but lacks some of the `byebug`
 features. GitLab uses the [`pry-byebug`](https://github.com/deivid-rodriguez/pry-byebug)
 gem. This gem brings some capabilities `byebug` to `binding.pry`, so
-using that, will give you the most debugging powers.
+using that gives you the most debugging powers.
 
 ## `byebug`
 
@@ -104,7 +104,7 @@ You also can move around in the callstack with these commands:
 - `down`: Moves the stack frame down. Takes an optional numeric
   argument to move multiple frames.
 - `frame <n>`: Moves to a specific frame. Called without arguments
-  will show the current frame.
+  displays the current frame.
 
 ## Short commands
 
diff --git a/doc/development/python_guide/index.md b/doc/development/python_guide/index.md
index 22a01c3b877..7134d857e53 100644
--- a/doc/development/python_guide/index.md
+++ b/doc/development/python_guide/index.md
@@ -39,7 +39,7 @@ You can read more about it in: <https://github.com/pyenv/pyenv-installer#prerequ
 
 ### Shell integration
 
-Pyenv installation will add required changes to Bash. If you use a different shell,
+Pyenv installation adds required changes to Bash. If you use a different shell,
 check for any additional steps required for it.
 
 For Fish, you can install a plugin for [Fisher](https://github.com/jorgebucaran/fisher):
@@ -63,13 +63,13 @@ on the main project level, so we can run that on our development machines.
 Recently, an equivalent to the `Gemfile` and the [Bundler](https://bundler.io/) project has been introduced to Python:
 `Pipfile` and [Pipenv](https://pipenv.readthedocs.io/en/latest/).
 
-You will now find a `Pipfile` with the dependencies in the root folder. To install them, run:
+A `Pipfile` with the dependencies now exists in the root folder. To install them, run:
 
 ```shell
 pipenv install
 ```
 
-Running this command will install both the required Python version as well as required pip dependencies.
+Running this command installs both the required Python version as well as required pip dependencies.
 
 ## Use instructions
 
@@ -80,5 +80,5 @@ of the application. With Pipenv, this is a simple as running:
 pipenv shell
 ```
 
-After running that command, you can run GitLab on the same shell and it will be using the Python and dependencies
+After running that command, you can run GitLab on the same shell and it uses the Python and dependencies
 installed from the `pipenv install` command.
diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md
index 2dca747425c..c129a435649 100644
--- a/doc/development/rake_tasks.md
+++ b/doc/development/rake_tasks.md
@@ -61,7 +61,7 @@ bin/rake "gitlab:seed:insights:issues[group-path/project-path]"
 ```
 
 By default, this seeds an average of 10 issues per week for the last 52 weeks
-per project. All issues will also be randomly labeled with team, type, severity,
+per project. All issues are also randomly labeled with team, type, severity,
 and priority.
 
 #### Seeding groups with sub-groups
@@ -116,8 +116,8 @@ so no worries about missing errors.
 There are a few environment flags you can pass to change how projects are seeded
 
 - `SIZE`: defaults to `8`, max: `32`. Amount of projects to create.
-- `LARGE_PROJECTS`: defaults to false. If set will clone 6 large projects to help with testing.
-- `FORK`: defaults to false. If set to `true` will fork `torvalds/linux` five times. Can also be set to an existing project full_path and it will fork that instead.
+- `LARGE_PROJECTS`: defaults to false. If set, clones 6 large projects to help with testing.
+- `FORK`: defaults to false. If set to `true`, forks `torvalds/linux` five times. Can also be set to an existing project `full_path` to fork that instead.
 
 ## Run tests
 
@@ -132,10 +132,10 @@ In order to run the test you can use the following commands:
 `bin/rake spec` takes significant time to pass.
 Instead of running the full test suite locally, you can save a lot of time by running
 a single test or directory related to your changes. After you submit a merge request,
-CI will run full test suite for you. Green CI status in the merge request means
+CI runs full test suite for you. Green CI status in the merge request means
 full test suite is passed.
 
-You can't run `rspec .` since this will try to run all the `_spec.rb`
+You can't run `rspec .` since this tries to run all the `_spec.rb`
 files it can find, also the ones in `/tmp`
 
 You can pass RSpec command line options to the `spec:unit`,
@@ -157,7 +157,7 @@ To run several tests inside one directory:
 speeds up development by keeping your application running in the background so
 you don't need to boot it every time you run a test, Rake task or migration.
 
-If you want to use it, you'll need to export the `ENABLE_SPRING` environment
+If you want to use it, you must export the `ENABLE_SPRING` environment
 variable to `1`:
 
 ```shell
@@ -180,7 +180,7 @@ environment you can do so with the following command:
 RAILS_ENV=production NODE_ENV=production bundle exec rake gitlab:assets:compile
 ```
 
-This will compile and minify all JavaScript and CSS assets and copy them along
+This compiles and minifies all JavaScript and CSS assets and copy them along
 with all other frontend assets (images, fonts, etc) into `/public/assets` where
 they can be easily inspected.
 
@@ -200,7 +200,7 @@ following:
 bundle exec rake gemojione:digests
 ```
 
-This will update the file `fixtures/emojis/digests.json` based on the currently
+This updates the file `fixtures/emojis/digests.json` based on the currently
 available Emoji.
 
 To generate a sprite file containing all the Emoji, run:
diff --git a/doc/development/redis.md b/doc/development/redis.md
index 7ee8afda36a..6b5a6962ccf 100644
--- a/doc/development/redis.md
+++ b/doc/development/redis.md
@@ -43,9 +43,9 @@ a single Redis server. This means that keys should **always** be
 globally unique across all categories.
 
 It is usually better to use immutable identifiers - project ID rather than
-full path, for instance - in Redis key names. If full path is used, the key will
-stop being consulted if the project is renamed. If the contents of the key are
-invalidated by a name change, it is better to include a hook that will expire
+full path, for instance - in Redis key names. If full path is used, the key
+stops being consulted if the project is renamed. If the contents of the key are
+invalidated by a name change, it is better to include a hook that expires
 the entry, instead of relying on the key changing.
 
 ### Multi-key commands
@@ -195,7 +195,7 @@ provides a convenient interface for adding and counting values in HyperLogLogs.
 For cases where we need to efficiently check the whether an item is in a group
 of items, we can use a Redis set.
 [`Gitlab::SetCache`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/set_cache.rb)
-provides an `#include?` method that will use the
+provides an `#include?` method that uses the
 [`SISMEMBER`](https://redis.io/commands/sismember) command, as well as `#read`
 to fetch all entries in the set.
 
diff --git a/doc/development/shell_commands.md b/doc/development/shell_commands.md
index 25113b4ac29..e9a50a2e27b 100644
--- a/doc/development/shell_commands.md
+++ b/doc/development/shell_commands.md
@@ -53,7 +53,7 @@ system(*%W(#{Gitlab.config.git.bin_path} branch -d -- #{branch_name}))
 
 ## Bypass the shell by splitting commands into separate tokens
 
-When we pass shell commands as a single string to Ruby, Ruby will let `/bin/sh` evaluate the entire string. Essentially, we are asking the shell to evaluate a one-line script. This creates a risk for shell injection attacks. It is better to split the shell command into tokens ourselves. Sometimes we use the scripting capabilities of the shell to change the working directory or set environment variables. All of this can also be achieved securely straight from Ruby
+When we pass shell commands as a single string to Ruby, Ruby lets `/bin/sh` evaluate the entire string. Essentially, we are asking the shell to evaluate a one-line script. This creates a risk for shell injection attacks. It is better to split the shell command into tokens ourselves. Sometimes we use the scripting capabilities of the shell to change the working directory or set environment variables. All of this can also be achieved securely straight from Ruby
 
 ```ruby
 # Wrong
diff --git a/doc/subscriptions/gitlab_com/index.md b/doc/subscriptions/gitlab_com/index.md
index 2a35898b5fd..8acb74ade49 100644
--- a/doc/subscriptions/gitlab_com/index.md
+++ b/doc/subscriptions/gitlab_com/index.md
@@ -112,6 +112,7 @@ to the **Billing** section of the relevant namespace:
   | **Seats owed**              | If your maximum seats used exceeds the seats in your subscription, you owe an additional fee for the users you've added.             |
   | **Subscription start date** | Date your subscription started. If this is for a Free plan, is the date you transitioned off your group's paid plan.                    |
   | **Subscription end date**   | Date your current subscription ends. Does not apply to Free plans.                                                                  |
+  | **Billable users list**   | List of users that belong to your group subscription. Does not apply to Free plans.                                                       |
 
 ## Renew your GitLab.com subscription
 
@@ -215,6 +216,10 @@ To upgrade your [GitLab tier](https://about.gitlab.com/pricing/):
 
 When the purchase has been processed, you receive confirmation of your new subscription tier.
 
+## See your billable users list
+
+To see a list of your billable users on your GitLab group page go to **Settings > Billing**. This page provides information about your subscription and occupied seats for your group which is the list of billable users for your particular group.
+
 ## Subscription expiry
 
 When your subscription or trial expires, GitLab does not delete your data, but
diff --git a/spec/models/user_spec.rb b/spec/models/user_spec.rb
index 87dab84fe7b..6b6f57c672a 100644
--- a/spec/models/user_spec.rb
+++ b/spec/models/user_spec.rb
@@ -2965,6 +2965,49 @@ RSpec.describe User do
     end
   end
 
+  describe '#solo_owned_groups' do
+    let_it_be_with_refind(:user) { create(:user) }
+
+    subject(:solo_owned_groups) { user.solo_owned_groups }
+
+    context 'no owned groups' do
+      it { is_expected.to be_empty }
+    end
+
+    context 'has owned groups' do
+      let_it_be(:group) { create(:group) }
+
+      before do
+        group.add_owner(user)
+      end
+
+      context 'not solo owner' do
+        let_it_be(:user2) { create(:user) }
+
+        before do
+          group.add_owner(user2)
+        end
+
+        it { is_expected.to be_empty }
+      end
+
+      context 'solo owner' do
+        it { is_expected.to include(group) }
+
+        it 'avoids N+1 queries' do
+          fresh_user = User.find(user.id)
+          control_count = ActiveRecord::QueryRecorder.new do
+            fresh_user.solo_owned_groups
+          end.count
+
+          create(:group).add_owner(user)
+
+          expect { solo_owned_groups }.not_to exceed_query_limit(control_count)
+        end
+      end
+    end
+  end
+
   describe "#recent_push" do
     let(:user) { build(:user) }
     let(:project) { build(:project) }