Add latest changes from gitlab-org/gitlab@master

11 files changed, 19 insertions, 20 deletions

diff --git a/doc/architecture/blueprints/database/scalability/patterns/read_mostly.md b/doc/architecture/blueprints/database/scalability/patterns/read_mostly.md
index bd87573a88e..02b56841507 100644
--- a/doc/architecture/blueprints/database/scalability/patterns/read_mostly.md
+++ b/doc/architecture/blueprints/database/scalability/patterns/read_mostly.md
@@ -1,6 +1,6 @@
 ---
 stage: Enablement
-group: database
+group: Database
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 comments: false
 description: 'Learn how to scale operating on read-mostly data at scale'
diff --git a/doc/architecture/blueprints/database/scalability/patterns/time_decay.md b/doc/architecture/blueprints/database/scalability/patterns/time_decay.md
index 6e0187a8d74..9309c581d54 100644
--- a/doc/architecture/blueprints/database/scalability/patterns/time_decay.md
+++ b/doc/architecture/blueprints/database/scalability/patterns/time_decay.md
@@ -1,6 +1,6 @@
 ---
 stage: Enablement
-group: database
+group: Database
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 comments: false
 description: 'Learn how to operate on large time-decay data'
diff --git a/doc/architecture/blueprints/database_scaling/size-limits.md b/doc/architecture/blueprints/database_scaling/size-limits.md
index 107cf0bb248..d63aa3bd4e8 100644
--- a/doc/architecture/blueprints/database_scaling/size-limits.md
+++ b/doc/architecture/blueprints/database_scaling/size-limits.md
@@ -33,7 +33,7 @@ graph LR
 Large tables on GitLab.com are a major problem - for both operations and development. They cause a variety of problems:
 
 1. **Query timings** and hence overall application performance suffers
-1. **Table maintenance** becomes much more costly. Vacuum activity has become a significant concern on GitLab.com - with large tables only seeing infrequent (e.g. once per day) and vacuum runs taking many hours to complete. This has various negative consequences and a very large table has potential to impact seemingly unrelated parts of the database and hence overall application performance suffers.
+1. **Table maintenance** becomes much more costly. Vacuum activity has become a significant concern on GitLab.com - with large tables only seeing infrequent (once per day) processing and vacuum runs taking many hours to complete. This has various negative consequences and a very large table has potential to impact seemingly unrelated parts of the database and hence overall application performance suffers.
 1. **Data migrations** on large tables are significantly more complex to implement and incur development overhead. They have potential to cause stability problems on GitLab.com and take a long time to execute on large datasets.
 1. **Indexes size** is significant. This directly impacts performance as smaller parts of the index are kept in memory and also makes the indexes harder to maintain (think repacking).
 1. **Index creation times** go up significantly - in 2021, we see btree creation take up to 6 hours for a single btree index. This impacts our ability to deploy frequently and leads to vacuum-related problems (delayed cleanup).
@@ -141,7 +141,7 @@ There is no standard solution to reduce table sizes - there are many!
 1. **Partitioning**: Apply a partitioning scheme if there is a common access dimension.
 1. **Normalization**: Review relational modeling and apply normalization techniques to remove duplicate data
 1. **Vertical table splits**: Review column usage and split table vertically.
-1. **Externalize**: Move large data types out of the database entirely. For example, JSON documents, especially when not used for filtering, may be better stored outside the database, e.g. in object storage.
+1. **Externalize**: Move large data types out of the database entirely. For example, JSON documents, especially when not used for filtering, may be better stored outside the database, for example, in object storage.
 
 NOTE:
 While we're targeting to limit physical table sizes, we consider retaining or improving performance a goal, too.
diff --git a/doc/development/snowplow/index.md b/doc/development/snowplow/index.md
index 59361e5206c..527b4292b23 100644
--- a/doc/development/snowplow/index.md
+++ b/doc/development/snowplow/index.md
@@ -551,14 +551,14 @@ Snowplow Micro is a Docker-based solution for testing frontend and backend event
    update application_settings set snowplow_collector_hostname='localhost:9090', snowplow_enabled=true, snowplow_cookie_domain='.gitlab.com';
    ```
 
-1. Update `DEFAULT_SNOWPLOW_OPTIONS` in `app/assets/javascripts/tracking/index.js` to remove `forceSecureTracker: true`:
+1. Update `DEFAULT_SNOWPLOW_OPTIONS` in `app/assets/javascripts/tracking/constants.js` to remove `forceSecureTracker: true`:
 
    ```diff
-   diff --git a/app/assets/javascripts/tracking/index.js b/app/assets/javascripts/tracking/index.js
-   index 0a1211d0a76..3b98c8f28f2 100644
-   --- a/app/assets/javascripts/tracking/index.js
-   +++ b/app/assets/javascripts/tracking/index.js
-   @@ -7,7 +7,6 @@ const DEFAULT_SNOWPLOW_OPTIONS = {
+   diff --git a/app/assets/javascripts/tracking/constants.js b/app/assets/javascripts/tracking/constants.js
+   index 598111e4086..eff38074d4c 100644
+   --- a/app/assets/javascripts/tracking/constants.js
+   +++ b/app/assets/javascripts/tracking/constants.js
+   @@ -7,7 +7,6 @@ export const DEFAULT_SNOWPLOW_OPTIONS = {
       appId: '',
       userFingerprint: false,
       respectDoNotTrack: true,
@@ -566,7 +566,6 @@ Snowplow Micro is a Docker-based solution for testing frontend and backend event
       eventMethod: 'post',
       contexts: { webPage: true, performanceTiming: true },
       formTracking: false,
-
    ```
 
 1. Update `snowplow_options` in `lib/gitlab/tracking.rb` to add `protocol` and `port`:
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 9db8631a6a5..a0587c6ef8a 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -40,7 +40,7 @@ can't be terminated and its memory usage grows over time.
 
 ## Select a version to install
 
-Make sure you view [this installation guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/installation.md) from the branch (version) of GitLab you would like to install (e.g., `11-7-stable`).
+Make sure you view [this installation guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/installation.md) from the branch (version) of GitLab you would like to install (for example, `11-7-stable`).
 You can select the branch in the version dropdown in the top left corner of GitLab (below the menu bar).
 
 If the highest number stable branch is unclear, check the [GitLab blog](https://about.gitlab.com/blog/) for installation guide links by version.
diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md
index 5b827d23772..ba3f246f5f5 100644
--- a/doc/integration/kerberos.md
+++ b/doc/integration/kerberos.md
@@ -261,7 +261,7 @@ offers only `basic` authentication.
    kerberos:
      # Dedicated port: Git before 2.4 does not fall back to Basic authentication if Negotiate fails.
      # To support both Basic and Negotiate methods with older versions of Git, configure
-     # nginx to proxy GitLab on an extra port (e.g. 8443) and uncomment the following lines
+     # nginx to proxy GitLab on an extra port (for example: 8443) and uncomment the following lines
      # to dedicate this port to Kerberos authentication. (default: false)
      use_dedicated_port: true
      port: 8443
diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md
index e67b6a45280..1ab343d75fb 100644
--- a/doc/user/project/import/github.md
+++ b/doc/user/project/import/github.md
@@ -179,8 +179,8 @@ Sidekiq workers that process the following queues:
 
 For an optimal experience, it's recommended having at least 4 Sidekiq processes (each running a number of threads equal
 to the number of CPU cores) that *only* process these queues. It's also recommended that these processes run on separate
-servers. For 4 servers with 8 cores this means you can import up to 32 objects (e.g., issues) in parallel.
+servers. For 4 servers with 8 cores this means you can import up to 32 objects (for example, issues) in parallel.
 
 Reducing the time spent in cloning a repository can be done by increasing network throughput, CPU capacity, and disk
-performance (e.g., by using high performance SSDs) of the disks that store the Git repositories (for your GitLab instance).
+performance (by using high performance SSDs, for example) of the disks that store the Git repositories (for your GitLab instance).
 Increasing the number of Sidekiq workers will *not* reduce the time spent cloning repositories.
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index d18858f647c..44225ac2921 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -94,7 +94,7 @@ Triggered when you push to the repository except when pushing tags.
 
 NOTE:
 When more than 20 commits are pushed at once, the `commits` webhook
-attribute only contains the first 20 for performance reasons. Loading
+attribute only contains the newest 20 for performance reasons. Loading
 detailed commit data is expensive. Note that despite only 20 commits being
 present in the `commits` attribute, the `total_commits_count` attribute contains the actual total.
 
diff --git a/doc/user/project/merge_requests/approvals/index.md b/doc/user/project/merge_requests/approvals/index.md
index 06440e10f0d..47744edd5ce 100644
--- a/doc/user/project/merge_requests/approvals/index.md
+++ b/doc/user/project/merge_requests/approvals/index.md
@@ -116,6 +116,6 @@ important to describe those, too. Think of things that may go wrong and include
 This is important to minimize requests for support, and to avoid doc comments with
 questions that you know someone might ask.
 
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+Each scenario can be a third-level heading, for example, `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
 but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
index 8c77714a2de..51f1ec96c22 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
@@ -139,7 +139,7 @@ If you're using Cloudflare, check
 > - **Do not** use a CNAME record if you want to point your
   `domain.com` to your GitLab Pages site. Use an `A` record instead.
 > - **Do not** add any special chars after the default Pages
-  domain. E.g., don't point `subdomain.domain.com` to
+  domain. For example, don't point `subdomain.domain.com` to
   or `namespace.gitlab.io/`. Some domain hosting providers may request a trailing dot (`namespace.gitlab.io.`), though.
 > - GitLab Pages IP on GitLab.com [was changed](https://about.gitlab.com/releases/2017/03/06/we-are-changing-the-ip-of-gitlab-pages-on-gitlab-com/) in 2017.
 > - GitLab Pages IP on GitLab.com [has changed](https://about.gitlab.com/blog/2018/07/19/gcp-move-update/#gitlab-pages-and-custom-domains)
@@ -315,6 +315,6 @@ important to describe those, too. Think of things that may go wrong and include
 This is important to minimize requests for support, and to avoid doc comments with
 questions that you know someone might ask.
 
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+Each scenario can be a third-level heading, for example, `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
 but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
index f0a922ff390..ee1004a3416 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
@@ -99,6 +99,6 @@ important to describe those, too. Think of things that may go wrong and include
 This is important to minimize requests for support, and to avoid doc comments with
 questions that you know someone might ask.
 
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+Each scenario can be a third-level heading, for example, `### Getting error message X`.
 If you have none to add when creating a doc, leave this section in place
 but commented out to help encourage others to add to it in the future. -->