Add latest changes from gitlab-org/gitlab@master

4 files changed, 6 insertions, 5 deletions

diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md
index c042e3e9872..322b3b3fe4d 100644
--- a/doc/administration/geo/disaster_recovery/background_verification.md
+++ b/doc/administration/geo/disaster_recovery/background_verification.md
@@ -176,7 +176,7 @@ progress to include them in [ee-1430]. For now, you can verify their integrity
 manually by following [these instructions][foreground-verification] on both
 nodes, and comparing the output between them.
 
-In GitLab EE 12.1, Geo calculates checksums for attachments, LFS objects and
+In GitLab EE 12.1, Geo calculates checksums for attachments, LFS objects, and
 archived traces on secondary nodes after the transfer, compares it with the
 stored checksums, and rejects transfers if mismatched. Please note that Geo
 currently does not support an automatic way to verify these data if they have
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index cd3d5a88de7..25050e4b13e 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -187,7 +187,7 @@ access to the **primary** node during the maintenance window.
 1. On the **secondary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues**
    and wait for all the `geo` queues to drop to 0 queued and 0 running jobs.
 1. On the **secondary** node, use [these instructions][foreground-verification]
-   to verify the integrity of CI artifacts, LFS objects and uploads in file
+   to verify the integrity of CI artifacts, LFS objects, and uploads in file
    storage.
 
 At this point, your **secondary** node will contain an up-to-date copy of everything the
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index 75ce7503c34..6b1b3131a96 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -13,7 +13,7 @@ We currently distinguish between three different data types:
 - [Blobs](#blobs)
 - [Database](#database)
 
-See the list below of each feature or component we replicate, its corresponding data type, replication and
+See the list below of each feature or component we replicate, its corresponding data type, replication, and
 verification methods:
 
 | Type     | Feature / component                           | Replication method                          | Verification method  |
diff --git a/doc/administration/geo/replication/index.md b/doc/administration/geo/replication/index.md
index 4eaf6a88575..ccc8b9ecd2d 100644
--- a/doc/administration/geo/replication/index.md
+++ b/doc/administration/geo/replication/index.md
@@ -12,7 +12,8 @@ Replication with Geo is the solution for widely distributed development teams.
 
 Fetching large repositories can take a long time for teams located far from a single GitLab instance.
 
-Geo provides local, read-only instances of your GitLab instances, reducing the time it takes to clone and fetch large repositories and speeding up development.
+Geo provides local, read-only instances of your GitLab instances. This can reduce the time it takes
+to clone and fetch large repositories, speeding up development.
 
 NOTE: **Note:**
 Check the [requirements](#requirements-for-running-geo) carefully before setting up Geo.
@@ -269,7 +270,7 @@ For answers to common questions, see the [Geo FAQ](faq.md).
 
 Since GitLab 9.5, Geo stores structured log messages in a `geo.log` file. For Omnibus installations, this file is at `/var/log/gitlab/gitlab-rails/geo.log`.
 
-This file contains information about when Geo attempts to sync repositories and files. Each line in the file contains a separate JSON entry that can be ingested into Elasticsearch, Splunk, etc.
+This file contains information about when Geo attempts to sync repositories and files. Each line in the file contains a separate JSON entry that can be ingested into, for example, Elasticsearch or Splunk.
 
 For example: