Remove more future tense from documentation

doc/administration/gitaly/index.md

@@ -22,11 +22,15 @@ In the Gitaly documentation:
 GitLab end users do not have direct access to Gitaly. Gitaly only manages Git
 repository access for GitLab. Other types of GitLab data aren't accessed using Gitaly.
 
+<!-- vale gitlab.FutureTense = NO -->
+
 WARNING:
 From GitLab 13.0, Gitaly support for NFS is deprecated. As of GitLab 14.0, NFS-related issues
 with Gitaly will no longer be addressed. Upgrade to [Gitaly Cluster](praefect.md) as soon as
-possible. Watch for [tools to enable bulk move](https://gitlab.com/groups/gitlab-org/-/epics/4916)
-of projects to Gitaly Cluster.
+possible. Tools to [enable bulk moves](https://gitlab.com/groups/gitlab-org/-/epics/4916)
+of projects to Gitaly Cluster are planned.
+
+<!-- vale gitlab.FutureTense = YES -->
 
 ## Architecture
 

doc/administration/integration/terminal.md

@@ -27,7 +27,7 @@ In brief:
 - When a user navigates to the terminal page for an environment, they are served
   a JavaScript application that opens a WebSocket connection back to GitLab.
 - The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
-   rather than the Rails application server.
+  rather than the Rails application server.
 - Workhorse queries Rails for connection details and user permissions. Rails
   queries Kubernetes for them in the background using [Sidekiq](../troubleshooting/sidekiq.md).
 - Workhorse acts as a proxy server between the user's browser and the Kubernetes
@@ -44,7 +44,7 @@ everything protected with authorization guards. This is described in more
 detail below.
 
 - Interactive web terminals are completely disabled unless [`[session_server]`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section) is configured.
-- Every time the runner starts, it will generate an `x509` certificate that will be used for a `wss` (Web Socket Secure) connection.
+- Every time the runner starts, it generates an `x509` certificate that is used for a `wss` (Web Socket Secure) connection.
 - For every created job, a random URL is generated which is discarded at the end of the job. This URL is used to establish a web socket connection. The URL for the session is in the format `(IP|HOST):PORT/session/$SOME_HASH`, where the `IP/HOST` and `PORT` are the configured [`listen_address`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section).
 - Every session URL that is created has an authorization header that needs to be sent, to establish a `wss` connection.
 - The session URL is not exposed to the users in any way. GitLab holds all the state internally and proxies accordingly.
@@ -72,7 +72,7 @@ guides document the necessary steps for a selection of popular reverse proxies:
 - [HAProxy](https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy/)
 - [Varnish](https://varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
 
-Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so
+Workhorse doesn't let WebSocket requests through to non-WebSocket endpoints, so
 it's safe to enable support for these headers globally. If you'd rather had a
 narrower set of rules, you can restrict it to URLs ending with `/terminal.ws`
 (although this may still have a few false positives).
@@ -85,7 +85,7 @@ document for more details.
 
 If you'd like to disable web terminal support in GitLab, just stop passing
 the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse
-proxy in the chain. For most users, this will be the NGINX server bundled with
+proxy in the chain. For most users, this is the NGINX server bundled with
 Omnibus GitLab, in which case, you need to:
 
 - Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
@@ -95,9 +95,9 @@ Omnibus GitLab, in which case, you need to:
 For your own load balancer, just reverse the configuration changes recommended
 by the above guides.
 
-When these headers are not passed through, Workhorse will return a
+When these headers are not passed through, Workhorse returns a
 `400 Bad Request` response to users attempting to use a web terminal. In turn,
-they will receive a `Connection failed` message.
+they receive a `Connection failed` message.
 
 ## Limiting WebSocket connection time