Add latest changes from gitlab-org/gitlab@master

11 files changed, 32 insertions, 30 deletions

diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md
index 01b621b6631..7fe047b380b 100644
--- a/doc/development/adding_database_indexes.md
+++ b/doc/development/adding_database_indexes.md
@@ -20,8 +20,8 @@ existing indexes need to be updated. The more indexes there are the slower this
 can potentially become. Indexes can also take up quite some disk space depending
 on the amount of data indexed and the index type. For example, PostgreSQL offers
 "GIN" indexes which can be used to index certain data types that can not be
-indexed by regular btree indexes. These indexes however generally take up more
-data and are slower to update compared to btree indexes.
+indexed by regular B-tree indexes. These indexes however generally take up more
+data and are slower to update compared to B-tree indexes.
 
 Because of all this one should not blindly add a new index for every column used
 to filter data by. Instead one should ask themselves the following questions:
diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md
index 36dc09b62b6..1f7a9ff09b9 100644
--- a/doc/development/application_limits.md
+++ b/doc/development/application_limits.md
@@ -21,7 +21,7 @@ In the `plan_limits` table, you have to create a new column and insert the
 limit values. It's recommended to create separate migration script files.
 
 1. Add new column to the `plan_limits` table with non-null default value
-   that represents desired limit, eg:
+   that represents desired limit, such as:
 
   ```ruby
   add_column(:plan_limits, :project_hooks, :integer, default: 100, null: false)
@@ -31,7 +31,7 @@ limit values. It's recommended to create separate migration script files.
   enabled. You should use this setting only in special and documented circumstances.
 
 1. (Optionally) Create the database migration that fine-tunes each level with
-    a desired limit using `create_or_update_plan_limit` migration helper, eg:
+    a desired limit using `create_or_update_plan_limit` migration helper, such as:
 
   ```ruby
   class InsertProjectHooksPlanLimits < ActiveRecord::Migration[5.2]
@@ -65,7 +65,7 @@ for plans that do not exist.
 #### Get current limit
 
 Access to the current limit can be done through the project or the namespace,
-eg:
+such as:
 
 ```ruby
 project.actual_limits.project_hooks
@@ -76,13 +76,13 @@ project.actual_limits.project_hooks
 There is one method `PlanLimits#exceeded?` to check if the current limit is
 being exceeded. You can use either an `ActiveRecord` object or an `Integer`.
 
-Ensures that the count of the records does not exceed the defined limit, eg:
+Ensures that the count of the records does not exceed the defined limit, such as:
 
 ```ruby
 project.actual_limits.exceeded?(:project_hooks, ProjectHook.where(project: project))
 ```
 
-Ensures that the number does not exceed the defined limit, eg:
+Ensures that the number does not exceed the defined limit, such as:
 
 ```ruby
 project.actual_limits.exceeded?(:project_hooks, 10)
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 1001a49be6a..83e40150e02 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -12,7 +12,7 @@ Both EE and CE require some add-on components called GitLab Shell and Gitaly. Th
 
 ## Components
 
-A typical install of GitLab will be on GNU/Linux. It uses NGINX or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and the [GitLab API](../api/README.md) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses Redis as a non-persistent database backend for job information, meta data, and incoming jobs.
+A typical install of GitLab will be on GNU/Linux. It uses NGINX or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and pre-compiled assets. GitLab serves web pages and the [GitLab API](../api/README.md) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses Redis as a non-persistent database backend for job information, meta data, and incoming jobs.
 
 We also support deploying GitLab on Kubernetes using our [GitLab Helm chart](https://docs.gitlab.com/charts/).
 
@@ -254,7 +254,7 @@ Elasticsearch is a distributed RESTful search engine built for the cloud.
 - Process: `gitaly`
 - GitLab.com: [Service Architecture](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#service-architecture)
 
-Gitaly is a service designed by GitLab to remove our need for NFS for Git storage in distributed deployments of GitLab (think GitLab.com or High Availability Deployments). As of 11.3.0, this service handles all Git level access in GitLab. You can read more about the project [in the project's readme](https://gitlab.com/gitlab-org/gitaly).
+Gitaly is a service designed by GitLab to remove our need for NFS for Git storage in distributed deployments of GitLab (think GitLab.com or High Availability Deployments). As of 11.3.0, this service handles all Git level access in GitLab. You can read more about the project [in the project's README](https://gitlab.com/gitlab-org/gitaly).
 
 #### Praefect
 
@@ -287,7 +287,7 @@ repository updates to secondary nodes.
 - Process: `gitlab-exporter`
 - GitLab.com: [Monitoring of GitLab.com](https://about.gitlab.com/handbook/engineering/monitoring/)
 
-GitLab Exporter is a process designed in house that allows us to export metrics about GitLab application internals to Prometheus. You can read more [in the project's readme](https://gitlab.com/gitlab-org/gitlab-exporter).
+GitLab Exporter is a process designed in house that allows us to export metrics about GitLab application internals to Prometheus. You can read more [in the project's README](https://gitlab.com/gitlab-org/gitlab-exporter).
 
 #### GitLab Pages
 
@@ -551,7 +551,7 @@ An external registry can also be configured to use GitLab as an auth endpoint.
 - Layer: Monitoring
 - GitLab.com: [Searching Sentry](https://about.gitlab.com/handbook/support/workflows/500_errors.html#searching-sentry)
 
-Sentry fundamentally is a service that helps you monitor and fix crashes in realtime.
+Sentry fundamentally is a service that helps you monitor and fix crashes in real time.
 The server is in Python, but it contains a full API for sending events from any language, in any application.
 
 For monitoring deployed apps, see the [Sentry integration docs](../user/project/operations/error_tracking.md)
@@ -657,7 +657,7 @@ When making a request to an HTTP Endpoint (think `/users/sign_in`) the request w
 
 ### GitLab Git Request Cycle
 
-Below we describe the different pathing 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 will take. There is some overlap with the Web Request Cycle but also some differences.
 
 ### Web Request (80/443)
 
@@ -790,7 +790,7 @@ ps aux | grep '^git'
 ```
 
 GitLab has several components to operate. It requires a persistent database
-(PostgreSQL) and Redis database, and uses Apache httpd or NGINX to proxypass
+(PostgreSQL) and Redis database, and uses Apache `httpd` or NGINX to proxypass
 Unicorn. All these components should run as different system users to GitLab
 (e.g., `postgres`, `redis` and `www-data`, instead of `git`).
 
@@ -866,7 +866,7 @@ NGINX:
 
 - `/var/log/nginx/` contains error and access logs.
 
-Apache httpd:
+Apache `httpd`:
 
 - [Explanation of Apache logs](https://httpd.apache.org/docs/2.2/logs.html).
 - `/var/log/apache2/` contains error and output logs (on Ubuntu).
@@ -880,7 +880,7 @@ PostgreSQL:
 
 - `/var/log/postgresql/*`
 
-### GitLab specific config files
+### GitLab specific configuration files
 
 GitLab has configuration files located in `/home/git/gitlab/config/*`. Commonly referenced config files include:
 
@@ -902,7 +902,7 @@ bundle exec rake gitlab:env:info RAILS_ENV=production
 bundle exec rake gitlab:check RAILS_ENV=production
 ```
 
-Note: It is recommended to log into the `git` user using `sudo -i -u git` or `sudo su - git`. While the sudo commands provided by gitlabhq work in Ubuntu they do not always work in RHEL.
+Note: It is recommended to log into the `git` user using `sudo -i -u git` or `sudo su - git`. While the sudo commands provided by GitLab work in Ubuntu they do not always work in RHEL.
 
 ## GitLab.com
 
diff --git a/doc/development/build_test_package.md b/doc/development/build_test_package.md
index 6784795e0bb..858ff41b685 100644
--- a/doc/development/build_test_package.md
+++ b/doc/development/build_test_package.md
@@ -24,7 +24,7 @@ trigger.
 
 If you want to create a package from a specific branch, commit or tag of any of
 the GitLab components (like GitLab Workhorse, Gitaly, GitLab Pages, etc.), you
-can specify the branch name, commit sha or tag in the component's respective
+can specify the branch name, commit SHA or tag in the component's respective
 `*_VERSION` file. For example, if you want to build a package that uses the
 branch `0-1-stable`, modify the content of `GITALY_SERVER_VERSION` to
 `0-1-stable` and push the commit. This will create a manual job that can be
diff --git a/doc/development/cicd/index.md b/doc/development/cicd/index.md
index db3f58d1d22..cf27fea9c80 100644
--- a/doc/development/cicd/index.md
+++ b/doc/development/cicd/index.md
@@ -10,7 +10,7 @@ the main components.
 ![CI software architecture](img/ci_architecture.png)
 <!-- Editable diagram available at https://app.diagrams.net/#G1LFl-KW4fgpBPzz8VIH9rsOlAH4t0xwKj -->
 
-On the left side we have the events that can trigger a pipeline based on various events (trigged by a user or automation):
+On the left side we have the events that can trigger a pipeline based on various events (triggered by a user or automation):
 
 - A `git push` is the most common event that triggers a pipeline.
 - The [Web API](../../api/pipelines.md#create-a-new-pipeline).
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 5e7f4ba9f37..9c6cb1d0237 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -314,7 +314,7 @@ experience, refactors the existing code). Then:
   - For non-mandatory suggestions, decorate with (non-blocking) so the author knows they can
     optionally resolve within the merge request or follow-up at a later stage.
 - After a round of line notes, it can be helpful to post a summary note such as
-  "LGTM :thumbsup:", or "Just a couple things to address."
+  "Looks good to me", or "Just a couple things to address."
 - Assign the merge request to the author if changes are required following your
   review.
 
@@ -381,7 +381,7 @@ Merge Results against the latest `master` at the time of the pipeline creation.
 
 One of the most difficult things during code review is finding the right
 balance in how deep the reviewer can interfere with the code created by a
-reviewee.
+author.
 
 - Learning how to find the right balance takes time; that is why we have
   reviewers that become maintainers after some time spent on reviewing merge
@@ -389,7 +389,7 @@ reviewee.
 - Finding bugs and improving code style is important, but thinking about good
   design is important as well. Building abstractions and good design is what
   makes it possible to hide complexity and makes future changes easier.
-- Asking the reviewee to change the design sometimes means the complete rewrite
+- Asking the author to change the design sometimes means the complete rewrite
   of the contributed code. It's usually a good idea to ask another maintainer or
   reviewer before doing it, but have the courage to do it when you believe it is
   important.
@@ -402,7 +402,7 @@ reviewee.
 - There is a difference in doing things right and doing things right now.
   Ideally, we should do the former, but in the real world we need the latter as
   well. A good example is a security fix which should be released as soon as
-  possible. Asking the reviewee to do the major refactoring in the merge
+  possible. Asking the author to do the major refactoring in the merge
   request that is an urgent fix should be avoided.
 - Doing things well today is usually better than doing something perfectly
   tomorrow. Shipping a kludge today is usually worse than doing something well
diff --git a/doc/development/database_debugging.md b/doc/development/database_debugging.md
index 3753baa3c63..629aea5b121 100644
--- a/doc/development/database_debugging.md
+++ b/doc/development/database_debugging.md
@@ -70,7 +70,9 @@ Use these instructions for exploring the GitLab database while developing with t
    1. **PostgreSQL user to authenticate as**: usually your local username, unless otherwise specified during PostgreSQL installation.
    1. **Password of the PostgreSQL user**: the password you set when installing PostgreSQL.
    1. **Port number to connect to**: `5432` (default).
-   1. **Use an ssl connection?** This depends on your installation. Options are:
+   1. <!-- vale gitlab.Spelling = NO -->
+      **Use an ssl connection?**
+      <!-- vale gitlab.rulename = NO --> This depends on your installation. Options are:
       - **Use Secure Connection**
       - **Standard Connection** (default)
    1. **(Optional) The database to connect to**: `gitlabhq_development`.
@@ -86,7 +88,7 @@ of the extension documentation.
 
 ### `ActiveRecord::PendingMigrationError` with Spring
 
-When running specs with the [Spring preloader](rake_tasks.md#speed-up-tests-rake-tasks-and-migrations),
+When running specs with the [Spring pre-loader](rake_tasks.md#speed-up-tests-rake-tasks-and-migrations),
 the test database can get into a corrupted state. Trying to run the migration or
 dropping/resetting the test database has no effect.
 
diff --git a/doc/development/database_review.md b/doc/development/database_review.md
index aa7ebb3756f..46ee982e4d4 100644
--- a/doc/development/database_review.md
+++ b/doc/development/database_review.md
@@ -87,7 +87,7 @@ the following preparations into account.
 #### Preparation when adding or modifying queries
 
 - Write the raw SQL in the MR description. Preferably formatted
-  nicely with [sqlformat.darold.net](http://sqlformat.darold.net) or
+  nicely with [pgFormatter](https://sqlformat.darold.net) or
   [paste.depesz.com](https://paste.depesz.com).
 - Include the output of `EXPLAIN (ANALYZE, BUFFERS)` of the relevant
   queries in the description. If the output is too long, wrap it in
diff --git a/doc/development/db_dump.md b/doc/development/db_dump.md
index bb740d12f7b..4095932e44c 100644
--- a/doc/development/db_dump.md
+++ b/doc/development/db_dump.md
@@ -2,7 +2,7 @@
 
 Sometimes it is useful to import the database from a production environment
 into a staging environment for testing. The procedure below assumes you have
-SSH+sudo access to both the production environment and the staging VM.
+SSH and `sudo` access to both the production environment and the staging VM.
 
 **Destroy your staging VM** when you are done with it. It is important to avoid
 data leaks.
@@ -20,7 +20,7 @@ sudo gitlab-ctl stop sidekiq
 ```
 
 Next, we let the production environment stream a compressed SQL dump to our
-local machine via SSH, and redirect this stream to a psql client on the staging
+local machine via SSH, and redirect this stream to a `psql` client on the staging
 VM.
 
 ```shell
diff --git a/doc/development/deleting_migrations.md b/doc/development/deleting_migrations.md
index 3ac039a1692..8aa16710d55 100644
--- a/doc/development/deleting_migrations.md
+++ b/doc/development/deleting_migrations.md
@@ -5,7 +5,7 @@ the possibility of the migration already been included in past releases or in th
 
 Because of it, it's not possible to delete existing migrations, as that could lead to:
 
-- Schema inconsistency, as changes introduced into the database were not rollbacked properly.
+- Schema inconsistency, as changes introduced into the database were not rolled back properly.
 - Leaving a record on the `schema_versions` table, that points out to migration that no longer exists on the codebase.
 
 Instead of deleting we can opt for disabling the migration.
@@ -22,7 +22,7 @@ Migrations can be disabled if:
 
 In order to disable a migration, the following steps apply to all types of migrations:
 
-1. Turn the migration into a noop by removing the code inside `#up`, `#down`
+1. Turn the migration into a no-op by removing the code inside `#up`, `#down`
   or `#perform` methods, and adding `#no-op` comment instead.
 1. Add a comment explaining why the code is gone.
 
diff --git a/doc/development/testing_guide/end_to_end/feature_flags.md b/doc/development/testing_guide/end_to_end/feature_flags.md
index 3bd07f17207..ada20cc9dad 100644
--- a/doc/development/testing_guide/end_to_end/feature_flags.md
+++ b/doc/development/testing_guide/end_to_end/feature_flags.md
@@ -26,4 +26,4 @@ end
 
 It's also possible to run an entire scenario with a feature flag enabled, without having to edit existing tests or write new ones.
 
-Please see the [QA readme](https://gitlab.com/gitlab-org/gitlab/tree/master/qa#running-tests-with-a-feature-flag-enabled) for details.
+Please see the [QA README](https://gitlab.com/gitlab-org/gitlab/tree/master/qa#running-tests-with-a-feature-flag-enabled) for details.