Fix more future tense instances

Rip out more instances of future tense, hooray! Present tense for all!

doc/development/application_limits.md

@@ -12,7 +12,7 @@ limits to GitLab.
 ## Documentation
 
 First of all, you have to gather information and decide which are the different
-limits that will be set for the different GitLab tiers. You also need to
+limits that are set for the different GitLab tiers. You also need to
 coordinate with others to [document](../administration/instance_limits.md)
 and communicate those limits.
 
@@ -63,7 +63,7 @@ It's recommended to create two separate migration script files.
    end
    ```
 
-   Some plans exist only on GitLab.com. This will be a no-op for plans
+   Some plans exist only on GitLab.com. This is a no-op for plans
    that do not exist.
 
 ### Plan limits validation

doc/development/architecture.md

@@ -282,8 +282,8 @@ When deployed, GitLab should be considered the amalgamation of the below process
 
 GitLab can be considered to have two layers from a process perspective:
 
-- **Monitoring**: Anything from this layer is not required to deliver GitLab the application, but will allow administrators more insight into their infrastructure and what the service as a whole is doing.
-- **Core**: Any process that is vital for the delivery of GitLab as a platform. If any of these processes halt there will be a GitLab outage. For the Core layer, you can further divide into:
+- **Monitoring**: Anything from this layer is not required to deliver GitLab the application, but allows administrators more insight into their infrastructure and what the service as a whole is doing.
+- **Core**: Any process that is vital for the delivery of GitLab as a platform. If any of these processes halt, a GitLab outage results. For the Core layer, you can further divide into:
   - **Processors**: These processes are responsible for actually performing operations and presenting the service.
   - **Data**: These services store/expose structured data for the GitLab service.
 
@@ -297,7 +297,7 @@ GitLab can be considered to have two layers from a process perspective:
 - Process: `alertmanager`
 - GitLab.com: [Monitoring of GitLab.com](https://about.gitlab.com/handbook/engineering/monitoring/)
 
-[Alert manager](https://prometheus.io/docs/alerting/latest/alertmanager/) is a tool provided by Prometheus that _"handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or Opsgenie. It also takes care of silencing and inhibition of alerts."_ You can read more in [issue #45740](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45740) about what we will be alerting on.
+[Alert manager](https://prometheus.io/docs/alerting/latest/alertmanager/) is a tool provided by Prometheus that _"handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or Opsgenie. It also takes care of silencing and inhibition of alerts."_ You can read more in [issue #45740](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45740) about what we alert on.
 
 #### Certificate management
 
@@ -600,7 +600,7 @@ GitLab packages the popular Database to provide storage for Application meta dat
 - Process: `postgres-exporter`
 - GitLab.com: [Monitoring of GitLab.com](https://about.gitlab.com/handbook/engineering/monitoring/)
 
-[`postgres_exporter`](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that will deliver data about PostgreSQL to Prometheus for use in Grafana Dashboards.
+[`postgres_exporter`](https://github.com/wrouesnel/postgres_exporter) is the community provided Prometheus exporter that delivers data about PostgreSQL to Prometheus for use in Grafana Dashboards.
 
 #### Prometheus
 
@@ -656,10 +656,10 @@ Redis is packaged to provide a place to store:
 
 The registry is what users use to store their own Docker images. The bundled
 registry uses NGINX as a load balancer and GitLab as an authentication manager.
-Whenever a client requests to pull or push an image from the registry, it will
-return a `401` response along with a header detailing where to get an
-authentication token, in this case the GitLab instance. The client will then
-request a pull or push auth token from GitLab and retry the original request
+Whenever a client requests to pull or push an image from the registry, it
+returns a `401` response along with a header detailing where to get an
+authentication token, in this case the GitLab instance. The client then
+requests a pull or push auth token from GitLab and retries the original request
 to the registry. Learn more about [token authentication](https://docs.docker.com/registry/spec/auth/token/).
 
 An external registry can also be configured to use GitLab as an auth endpoint.
@@ -710,7 +710,7 @@ disabled by default.
 - Process: `puma`
 - GitLab.com: [Puma](../user/gitlab_com/index.md#puma)
 
-[Puma](https://puma.io/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often process output you will see this as `bundle` or `config.ru` depending on the GitLab version.
+[Puma](https://puma.io/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often this displays in process output as `bundle` or `config.ru` depending on the GitLab version.
 
 #### Unicorn
 
@@ -727,7 +727,7 @@ disabled by default.
 - Process: `unicorn`
 - GitLab.com: [Unicorn](../user/gitlab_com/index.md#unicorn)
 
-[Unicorn](https://yhbt.net/unicorn/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often process output you will see this as `bundle` or `config.ru` depending on the GitLab version.
+[Unicorn](https://yhbt.net/unicorn/) is a Ruby application server that is used to run the core Rails Application that provides the user facing features in GitLab. Often this displays in process output as `bundle` or `config.ru` depending on the GitLab version.
 
 #### LDAP Authentication
 
@@ -792,16 +792,16 @@ It's important to understand the distinction as some processes are used in both
 
 ### GitLab Web HTTP request cycle
 
-When making a request to an HTTP Endpoint (think `/users/sign_in`) the request will take the following path through the GitLab Service:
+When making a request to an HTTP Endpoint (think `/users/sign_in`) the request takes the following path through the GitLab Service:
 
 - NGINX - Acts as our first line reverse proxy.
 - GitLab Workhorse - This determines if it needs to go to the Rails application or somewhere else to reduce load on Puma.
-- Puma - Since this is a web request, and it needs to access the application it will go to Puma.
+- Puma - Since this is a web request, and it needs to access the application, it routes to Puma.
 - PostgreSQL/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
 
 ### GitLab Git request cycle
 
-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.
+Below we describe the different paths that HTTP vs. SSH Git requests take. There is some overlap with the Web Request Cycle but also some differences.
 
 ### Web request (80/443)
 

doc/development/changelog.md

@@ -118,7 +118,7 @@ Its simplest usage is to provide the value for `title`:
 bin/changelog 'Hey DZ, I added a feature to GitLab!'
 ```
 
-If you want to generate a changelog entry for GitLab EE, you will need to pass
+If you want to generate a changelog entry for GitLab EE, you must pass
 the `--ee` option:
 
 ```plaintext
@@ -144,10 +144,10 @@ At this point the script would ask you to select the category of the change (map
 ```
 
 The entry filename is based on the name of the current Git branch. If you run
-the command above on a branch called `feature/hey-dz`, it will generate a
+the command above on a branch called `feature/hey-dz`, it generates a
 `changelogs/unreleased/feature-hey-dz.yml` file.
 
-The command will output the path of the generated file and its contents:
+The command outputs the path of the generated file and its contents:
 
 ```plaintext
 create changelogs/unreleased/my-feature.yml
@@ -175,7 +175,7 @@ type:
 You can pass the **`--amend`** argument to automatically stage the generated
 file and amend it to the previous commit.
 
-If you use **`--amend`** and don't provide a title, it will automatically use
+If you use **`--amend`** and don't provide a title, it uses
 the "subject" of the previous commit, which is the first line of the commit
 message:
 

doc/development/documentation/site_architecture/deployment_process.md

@@ -36,7 +36,7 @@ and tag all tooling images locally:
    ```
 
 For each image, there's a manual job under the `images` stage in
-[`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/.gitlab-ci.yml) which can be invoked at will.
+[`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/.gitlab-ci.yml) which can be invoked at any time.
 
 ## Update an old Docker image with new upstream docs content
 
@@ -51,7 +51,7 @@ Porting changes to older branches can have unintended effects as we're constantl
 changing the backend of the website. Use only when you know what you're doing
 and make sure to test locally.
 
-The website will keep changing and being improved. In order to consolidate
+The website keeps changing and being improved. In order to consolidate
 those changes to the stable branches, we'd need to pick certain changes
 from time to time.
 

doc/development/documentation/site_architecture/index.md

@@ -46,7 +46,7 @@ from where content is sourced, the `gitlab-docs` project, and the published outp
     H -- symlink --> G
 ```
 
-You will not find any GitLab docs content in the `gitlab-docs` repository.
+GitLab docs content isn't kept in the `gitlab-docs` repository.
 All documentation files are hosted in the respective repository of each
 product, and all together are pulled to generate the docs website:
 
@@ -62,7 +62,7 @@ in order not to break any existing links throughout the internet, we still
 maintain the CE docs (`https://docs.gitlab.com/ce/`), although it is hidden
 from the website, and is now a symlink to the EE docs. When
 [Pages supports redirects](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/24),
-we will be able to remove this completely.
+we can remove this completely.
 
 ## Assets
 
@@ -179,7 +179,7 @@ we reference the array with a symbol (`:versions`).
 
 Whenever the custom CSS and JavaScript files under `content/assets/` change,
 make sure to bump their version in the front matter. This method guarantees that
-your changes will take effect by clearing the cache of previous files.
+your changes take effect by clearing the cache of previous files.
 
 Always use Nanoc's way of including those files, do not hardcode them in the
 layouts. For example use:
@@ -196,7 +196,7 @@ The links pointing to the files should be similar to:
 <%= @items['/path/to/assets/file.*'].path %>
 ```
 
-Nanoc will then build and render those links correctly according with what's
+Nanoc then builds and renders those links correctly according with what's
 defined in [`Rules`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/Rules).
 
 ## Linking to source files
@@ -236,7 +236,7 @@ If you’re a GitLab team member, find credentials for the Algolia dashboard
 in the shared [GitLab 1Password account](https://about.gitlab.com/handbook/security/#1password-for-teams).
 To receive weekly reports of the search usage, search the Google doc with
 title `Email, Slack, and GitLab Groups and Aliases`, search for `docsearch`,
-and add a comment with your email. You'll be added to the alias that gets the weekly
+and add a comment with your email to be added to the alias that gets the weekly
 reports.
 
 ## Monthly release process (versions)

doc/development/documentation/site_architecture/release_process.md

@@ -44,14 +44,14 @@ this needs to happen when the stable branches for all products have been created
    ```
 
     A new `Dockerfile.12.0` should have been created and `.gitlab-ci.yml` should
-    have the branches variables updated into a new branch. They will be automatically
+    have the branches variables updated into a new branch. They are automatically
     committed.
 
 1. Push the newly created branch, but **don't create a merge request**.
-   Once you push, the `image:docker-singe` job will create a new Docker image
+   After you push, the `image:docker-singe` job creates a new Docker image
    tagged with the branch name you created in the first step. In the end, the
-   image will be uploaded in the [Container Registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry)
-   and it will be listed under the `registry` environment folder at
+   image is uploaded in the [Container Registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry)
+   and it is listed under the `registry` environment folder at
    `https://gitlab.com/gitlab-org/gitlab-docs/-/environments/folders/registry` (must
    have developer access).
 
@@ -114,20 +114,20 @@ version and rotates the old one:
 
 The versions dropdown is in a way "hardcoded". When the site is built, it looks
 at the contents of `content/_data/versions.yaml` and based on that, the dropdown
-is populated. So, older branches will have different content, which means the
-dropdown will list one or more releases behind. Remember that the new changes of
+is populated. So, older branches have different content, which means the
+dropdown list one or more releases behind. Remember that the new changes of
 the dropdown are included in the unmerged `release-X-Y` branch.
 
 The content of `content/_data/versions.yaml` needs to change for all online
 versions (stable branches `X.Y` of the `gitlab-docs` project):
 
-1. Run the Rake task that will create all the respective merge requests needed to
-   update the dropdowns and will be set to automatically be merged when their
+1. Run the Rake task that creates all the respective merge requests needed to
+   update the dropdowns and are set to automatically be merged when their
    pipelines succeed:
 
    NOTE: **Note:**
    The `release-X-Y` branch needs to be present locally,
-   and you need to have switched to it, otherwise the Rake task will fail.
+   and you need to have switched to it, otherwise the Rake task fails.
 
    ```shell
    git checkout release-X-Y
@@ -144,7 +144,7 @@ In case a pipeline fails, see [troubleshooting](#troubleshooting).
 ## 5. Merge the release merge request
 
 The dropdown merge requests should have now been merged into their respective
-version (stable `X.Y` branch), which will trigger another pipeline. At this point,
+version (stable `X.Y` branch), which triggers another pipeline. At this point,
 you need to only babysit the pipelines and make sure they don't fail:
 
 1. Check the [pipelines page](https://gitlab.com/gitlab-org/gitlab-docs/pipelines)
@@ -152,9 +152,9 @@ you need to only babysit the pipelines and make sure they don't fail:
 1. After all the pipelines of the online versions succeed, merge the release merge request.
 1. Finally, run the
    [`Build docker images weekly` pipeline](https://gitlab.com/gitlab-org/gitlab-docs/pipeline_schedules)
-   that will build the `:latest` and `:archives` Docker images.
+   that builds the `:latest` and `:archives` Docker images.
 
-Once the scheduled pipeline succeeds, the docs site will be deployed with all
+Once the scheduled pipeline succeeds, the docs site is deployed with all
 new versions online.
 
 ## Troubleshooting

doc/development/pry_debugging.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ## Invoking pry debugging
 
 To invoke the debugger, place `binding.pry` somewhere in your
-code. When the Ruby interpreter hits that code, execution will stop,
+code. When the Ruby interpreter hits that code, execution stops,
 and you can type in commands to debug the state of the program
 
 ## `byebug` vs `binding.pry`
@@ -20,7 +20,7 @@ use the powerful Pry REPL.
 `binding.pry` uses Pry, but lacks some of the `byebug`
 features. GitLab uses the [`pry-byebug`](https://github.com/deivid-rodriguez/pry-byebug)
 gem. This gem brings some capabilities `byebug` to `binding.pry`, so
-using that, will give you the most debugging powers.
+using that gives you the most debugging powers.
 
 ## `byebug`
 
@@ -104,7 +104,7 @@ You also can move around in the callstack with these commands:
 - `down`: Moves the stack frame down. Takes an optional numeric
   argument to move multiple frames.
 - `frame <n>`: Moves to a specific frame. Called without arguments
-  will show the current frame.
+  displays the current frame.
 
 ## Short commands
 

doc/development/python_guide/index.md

@@ -39,7 +39,7 @@ You can read more about it in: <https://github.com/pyenv/pyenv-installer#prerequ
 
 ### Shell integration
 
-Pyenv installation will add required changes to Bash. If you use a different shell,
+Pyenv installation adds required changes to Bash. If you use a different shell,
 check for any additional steps required for it.
 
 For Fish, you can install a plugin for [Fisher](https://github.com/jorgebucaran/fisher):
@@ -63,13 +63,13 @@ on the main project level, so we can run that on our development machines.
 Recently, an equivalent to the `Gemfile` and the [Bundler](https://bundler.io/) project has been introduced to Python:
 `Pipfile` and [Pipenv](https://pipenv.readthedocs.io/en/latest/).
 
-You will now find a `Pipfile` with the dependencies in the root folder. To install them, run:
+A `Pipfile` with the dependencies now exists in the root folder. To install them, run:
 
 ```shell
 pipenv install
 ```
 
-Running this command will install both the required Python version as well as required pip dependencies.
+Running this command installs both the required Python version as well as required pip dependencies.
 
 ## Use instructions
 
@@ -80,5 +80,5 @@ of the application. With Pipenv, this is a simple as running:
 pipenv shell
 ```
 
-After running that command, you can run GitLab on the same shell and it will be using the Python and dependencies
+After running that command, you can run GitLab on the same shell and it uses the Python and dependencies
 installed from the `pipenv install` command.

doc/development/rake_tasks.md

@@ -61,7 +61,7 @@ bin/rake "gitlab:seed:insights:issues[group-path/project-path]"
 ```
 
 By default, this seeds an average of 10 issues per week for the last 52 weeks
-per project. All issues will also be randomly labeled with team, type, severity,
+per project. All issues are also randomly labeled with team, type, severity,
 and priority.
 
 #### Seeding groups with sub-groups
@@ -116,8 +116,8 @@ so no worries about missing errors.
 There are a few environment flags you can pass to change how projects are seeded
 
 - `SIZE`: defaults to `8`, max: `32`. Amount of projects to create.
-- `LARGE_PROJECTS`: defaults to false. If set will clone 6 large projects to help with testing.
-- `FORK`: defaults to false. If set to `true` will fork `torvalds/linux` five times. Can also be set to an existing project full_path and it will fork that instead.
+- `LARGE_PROJECTS`: defaults to false. If set, clones 6 large projects to help with testing.
+- `FORK`: defaults to false. If set to `true`, forks `torvalds/linux` five times. Can also be set to an existing project `full_path` to fork that instead.
 
 ## Run tests
 
@@ -132,10 +132,10 @@ In order to run the test you can use the following commands:
 `bin/rake spec` takes significant time to pass.
 Instead of running the full test suite locally, you can save a lot of time by running
 a single test or directory related to your changes. After you submit a merge request,
-CI will run full test suite for you. Green CI status in the merge request means
+CI runs full test suite for you. Green CI status in the merge request means
 full test suite is passed.
 
-You can't run `rspec .` since this will try to run all the `_spec.rb`
+You can't run `rspec .` since this tries to run all the `_spec.rb`
 files it can find, also the ones in `/tmp`
 
 You can pass RSpec command line options to the `spec:unit`,
@@ -157,7 +157,7 @@ To run several tests inside one directory:
 speeds up development by keeping your application running in the background so
 you don't need to boot it every time you run a test, Rake task or migration.
 
-If you want to use it, you'll need to export the `ENABLE_SPRING` environment
+If you want to use it, you must export the `ENABLE_SPRING` environment
 variable to `1`:
 
 ```shell
@@ -180,7 +180,7 @@ environment you can do so with the following command:
 RAILS_ENV=production NODE_ENV=production bundle exec rake gitlab:assets:compile
 ```
 
-This will compile and minify all JavaScript and CSS assets and copy them along
+This compiles and minifies all JavaScript and CSS assets and copy them along
 with all other frontend assets (images, fonts, etc) into `/public/assets` where
 they can be easily inspected.
 
@@ -200,7 +200,7 @@ following:
 bundle exec rake gemojione:digests
 ```
 
-This will update the file `fixtures/emojis/digests.json` based on the currently
+This updates the file `fixtures/emojis/digests.json` based on the currently
 available Emoji.
 
 To generate a sprite file containing all the Emoji, run:

doc/development/redis.md

@@ -43,9 +43,9 @@ a single Redis server. This means that keys should **always** be
 globally unique across all categories.
 
 It is usually better to use immutable identifiers - project ID rather than
-full path, for instance - in Redis key names. If full path is used, the key will
-stop being consulted if the project is renamed. If the contents of the key are
-invalidated by a name change, it is better to include a hook that will expire
+full path, for instance - in Redis key names. If full path is used, the key
+stops being consulted if the project is renamed. If the contents of the key are
+invalidated by a name change, it is better to include a hook that expires
 the entry, instead of relying on the key changing.
 
 ### Multi-key commands
@@ -195,7 +195,7 @@ provides a convenient interface for adding and counting values in HyperLogLogs.
 For cases where we need to efficiently check the whether an item is in a group
 of items, we can use a Redis set.
 [`Gitlab::SetCache`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/set_cache.rb)
-provides an `#include?` method that will use the
+provides an `#include?` method that uses the
 [`SISMEMBER`](https://redis.io/commands/sismember) command, as well as `#read`
 to fetch all entries in the set.
 

doc/development/shell_commands.md

@@ -53,7 +53,7 @@ system(*%W(#{Gitlab.config.git.bin_path} branch -d -- #{branch_name}))
 
 ## Bypass the shell by splitting commands into separate tokens
 
-When we pass shell commands as a single string to Ruby, Ruby will let `/bin/sh` evaluate the entire string. Essentially, we are asking the shell to evaluate a one-line script. This creates a risk for shell injection attacks. It is better to split the shell command into tokens ourselves. Sometimes we use the scripting capabilities of the shell to change the working directory or set environment variables. All of this can also be achieved securely straight from Ruby
+When we pass shell commands as a single string to Ruby, Ruby lets `/bin/sh` evaluate the entire string. Essentially, we are asking the shell to evaluate a one-line script. This creates a risk for shell injection attacks. It is better to split the shell command into tokens ourselves. Sometimes we use the scripting capabilities of the shell to change the working directory or set environment variables. All of this can also be achieved securely straight from Ruby
 
 ```ruby
 # Wrong