Change of future tense to present

doc/administration/auth/ldap/ldap-troubleshooting.md

@@ -27,7 +27,7 @@ Could not authenticate you from Ldapmain because "Connection timed out - user sp
 ```
 
 If your configured LDAP provider and/or endpoint is offline or otherwise
-unreachable by GitLab, no LDAP user will be able to authenticate and sign-in.
+unreachable by GitLab, no LDAP user is able to authenticate and sign-in.
 GitLab does not cache or store credentials for LDAP users to provide authentication
 during an LDAP outage.
 
@@ -181,14 +181,13 @@ user = User.find_by_any_email('email@example.com')
 user.username
 ```
 
-This will show you which user has this email address. One of two steps will
-have to be taken here:
+This shows you which user has this email address. One of two steps must be taken here:
 
 - To create a new GitLab user/username for this user when signing in with LDAP,
   remove the secondary email to remove the conflict.
 - To use an existing GitLab user/username for this user to use with LDAP,
   remove this email as a secondary email and make it a primary one so GitLab
-  will associate this profile to the LDAP identity.
+  associates this profile to the LDAP identity.
 
 The user can do either of these steps [in their
 profile](../../../user/profile/index.md#access-your-user-profile) or an administrator can do it.
@@ -227,7 +226,7 @@ output](#example-console-output-after-a-user-sync).
 
 ##### Example console output after a user sync **(PREMIUM SELF)**
 
-The output from a [manual user sync](#sync-all-users) will be very verbose, and a
+The output from a [manual user sync](#sync-all-users) is very verbose, and a
 single user's successful sync can look like this:
 
 ```shell
@@ -255,8 +254,8 @@ uid: John
 
 There's a lot here, so let's go over what could be helpful when debugging.
 
-First, GitLab will look for all users that have previously
-signed in with LDAP and iterate on them. Each user's sync will start with
+First, GitLab looks for all users that have previously
+signed in with LDAP and iterate on them. Each user's sync starts with
 the following line that contains the user's username and email, as they
 exist in GitLab now:
 
@@ -274,7 +273,7 @@ link between this user and the configured LDAP provider(s):
   Identity Load (0.9ms)  SELECT  "identities".* FROM "identities" WHERE "identities"."user_id" = 20 AND (provider LIKE 'ldap%') LIMIT 1
 ```
 
-The identity object will have the DN that GitLab will use to look for the user
+The identity object has the DN that GitLab uses to look for the user
 in LDAP. If the DN isn't found, the email is used instead. We can see that
 this user is found in LDAP:
 
@@ -294,18 +293,18 @@ following message instead:
 LDAP search error: No Such Object
 ```
 
-...in which case the user will be blocked:
+...in which case the user is blocked:
 
 ```shell
   User Update (0.4ms)  UPDATE "users" SET "state" = $1, "updated_at" = $2 WHERE "users"."id" = $3  [["state", "ldap_blocked"], ["updated_at", "2019-10-18 15:46:22.902177"], ["id", 20]]
 ```
 
-Once the user is found in LDAP the rest of the output will update the GitLab
+Once the user is found in LDAP, the rest of the output updates the GitLab
 database with any changes.
 
 #### Query a user in LDAP
 
-This will test that GitLab can reach out to LDAP and read a particular user.
+This tests that GitLab can reach out to LDAP and read a particular user.
 It can expose potential errors connecting to and/or querying LDAP
 that may seem to fail silently in the GitLab UI.
 

doc/administration/geo/replication/docker_registry.md

@@ -24,7 +24,7 @@ integrated [Container Registry](../../packages/container_registry.md#use-object-
 
 You can enable a storage-agnostic replication so it
 can be used for cloud or local storage. Whenever a new image is pushed to the
-**primary** site, each **secondary** site will pull it to its own container
+**primary** site, each **secondary** site pulls it to its own container
 repository.
 
 To configure Docker Registry replication:
@@ -70,12 +70,12 @@ We need to make Docker Registry send notification events to the
 
    NOTE:
    If you use an external Registry (not the one integrated with GitLab), you must add
-   these settings to its configuration yourself. In this case, you will also have to specify
+   these settings to its configuration yourself. In this case, you also have to specify
    notification secret in `registry.notification_secret` section of
    `/etc/gitlab/gitlab.rb` file.
 
    NOTE:
-   If you use GitLab HA, you will also have to specify
+   If you use GitLab HA, you also have to specify
    the notification secret in `registry.notification_secret` section of
    `/etc/gitlab/gitlab.rb` file for every web node.
 
@@ -95,7 +95,7 @@ expecting to see the Docker images replicated.
 
 Because we need to allow the **secondary** site to communicate securely with
 the **primary** site Container Registry, we need to have a single key
-pair for all the sites. The **secondary** site will use this key to
+pair for all the sites. The **secondary** site uses this key to
 generate a short-lived JWT that is pull-only-capable to access the
 **primary** site Container Registry.
 
@@ -126,5 +126,5 @@ For each application and Sidekiq node on the **secondary** site:
 
 To verify Container Registry replication is working, go to **Admin Area > Geo**
 (`/admin/geo/nodes`) on the **secondary** site.
-The initial replication, or "backfill", will probably still be in progress.
+The initial replication, or "backfill", is probably still in progress.
 You can monitor the synchronization process on each Geo site from the **primary** site's **Geo Nodes** dashboard in your browser.