Future tense cleanup, unowned files

Changes future tense to present tense in pages that have metadata of
group: unassigned.

doc/install/digitaloceandocker.md

@@ -12,7 +12,7 @@ recommended for ease of future upgrades or keeping the data you create.
 
 ## Initial setup
 
-In this guide you'll configure a Digital Ocean droplet and set up Docker
+This guide configures a Digital Ocean droplet and sets up Docker
 locally on either macOS or Linux.
 
 ### On macOS
@@ -39,10 +39,10 @@ The rest of the steps are identical for macOS and Linux.
 1. Login to Digital Ocean.
 1. Generate a new API token at <https://cloud.digitalocean.com/settings/api/tokens>.
 
-   This command will create a new DO droplet called `gitlab-test-env-do` that will act as a Docker host.
+   This command creates a new Digital Ocean droplet called `gitlab-test-env-do` that acts as a Docker host.
 
    NOTE:
-   4GB is the minimum requirement for a Docker host that will run more than one GitLab instance.
+   4GB is the minimum requirement for a Docker host that runs more than one GitLab instance.
 
    - RAM: 4GB
    - Name: `gitlab-test-env-do`
@@ -70,7 +70,7 @@ Resource: <https://docs.docker.com/machine/drivers/digital-ocean/>.
 
 ### Connect your shell to the new machine
 
-In this example we'll create a GitLab EE 8.10.8 instance.
+This example creates a GitLab EE 8.10.8 instance.
 
 First connect the Docker client to the Docker host you created previously.
 

doc/install/pivotal/index.md

@@ -10,7 +10,7 @@ WARNING:
 As of September 13, 2017, the GitLab Enterprise Plus for Pivotal Cloud Foundry
 tile on Pivotal Network has reached its End of Availability (“EoA”) and is no
 longer available for download or sale through Pivotal. Current customers with
-active subscriptions will continue to receive support from GitLab through their
+active subscriptions continue to receive support from GitLab through their
 subscription term. Pivotal and GitLab are collaborating on creating a new
 Kubernetes-based tile for the Pivotal Container Service. Please contact GitLab
 support with any questions regarding GitLab Enterprise Plus for Pivotal Cloud Foundry.

doc/security/webhooks.md

@@ -40,9 +40,9 @@ to endpoints like `http://localhost:123/some-resource/delete`.
 
 To prevent this type of exploitation from happening, starting with GitLab 10.6,
 all Webhook requests to the current GitLab instance server address and/or in a
-private network will be forbidden by default. That means that all requests made
+private network are forbidden by default. That means that all requests made
 to `127.0.0.1`, `::1` and `0.0.0.0`, as well as IPv4 `10.0.0.0/8`, `172.16.0.0/12`,
-`192.168.0.0/16` and IPv6 site-local (`ffc0::/10`) addresses won't be allowed.
+`192.168.0.0/16` and IPv6 site-local (`ffc0::/10`) addresses aren't allowed.
 
 This behavior can be overridden by enabling the option *"Allow requests to the
 local network from web hooks and services"* in the *"Outbound requests"* section
@@ -75,9 +75,9 @@ The allowlist can hold a maximum of 1000 entries. Each entry can be a maximum of
 255 characters.
 
 You can allow a particular port by specifying it in the allowlist entry.
-For example `127.0.0.1:8080` will only allow connections to port 8080 on `127.0.0.1`.
+For example `127.0.0.1:8080` only allows connections to port 8080 on `127.0.0.1`.
 If no port is mentioned, all ports on that IP/domain are allowed. An IP range
-will allow all ports on all IPs in that range.
+allows all ports on all IPs in that range.
 
 Example:
 

doc/system_hooks/system_hooks.md

@@ -249,7 +249,7 @@ Please refer to `group_rename` and `user_rename` for that case.
 }
 ```
 
-If the user is blocked via LDAP, `state` will be `ldap_blocked`.
+If the user is blocked via LDAP, `state` is `ldap_blocked`.
 
 **User renamed:**
 

doc/tools/email.md

@@ -8,13 +8,13 @@ type: howto, reference
 # Email from GitLab **(STARTER ONLY)**
 
 GitLab provides a simple tool to administrators for emailing all users, or users of
-a chosen group or project, right from the Admin Area. Users will receive the email
+a chosen group or project, right from the Admin Area. Users receive the email
 at their primary email address.
 
 ## Use-cases
 
 - Notify your users about a new project, a new feature, or a new product launch.
-- Notify your users about a new deployment, or that will be downtime expected
+- Notify your users about a new deployment, or that downtime is expected
   for a particular reason.
 
 ## Sending emails to users from within GitLab
@@ -24,9 +24,9 @@ at their primary email address.
 
    ![admin users](email1.png)
 
-1. Compose an email and choose where it will be sent (all users or users of a
+1. Compose an email and choose where to send it (all users or users of a
    chosen group or project). The email body only supports plain text messages.
-   HTML, Markdown, and other rich text formats are not supported, and will be
+   HTML, Markdown, and other rich text formats are not supported, and is
    sent as plain text to users.
 
    ![compose an email](email2.png)
@@ -40,7 +40,7 @@ Users can choose to unsubscribe from receiving emails from GitLab by following
 the unsubscribe link in the email. Unsubscribing is unauthenticated in order
 to keep this feature simple.
 
-On unsubscribe, users will receive an email notification that unsubscribe happened.
+On unsubscribe, users receive an email notification that unsubscribe happened.
 The endpoint that provides the unsubscribe option is rate-limited.
 
 <!-- ## Troubleshooting

doc/update/mysql_to_postgresql.md

@@ -51,7 +51,7 @@ For other distributions, follow the instructions in PostgreSQL's
 [download page](https://www.postgresql.org/download/) to add their repository
 and then install `pgloader`.
 
-If you are migrating to a Docker based installation, you will need to install
+If you are migrating to a Docker based installation, you must install
 pgloader within the container as it is not included in the container image.
 
 1. Start a shell session in the context of the running container:
@@ -69,7 +69,7 @@ pgloader within the container as it is not included in the container image.
 
 ## Omnibus GitLab installations
 
-For [Omnibus GitLab packages](https://about.gitlab.com/install/), you'll first
+For [Omnibus GitLab packages](https://about.gitlab.com/install/), you first
 need to enable the bundled PostgreSQL:
 
 1. Stop GitLab:
@@ -84,13 +84,13 @@ need to enable the bundled PostgreSQL:
    postgresql['enable'] = true
    ```
 
-1. Edit `/etc/gitlab/gitlab.rb` to use the bundled PostgreSQL. Please check
-   all the settings beginning with `db_`, such as `gitlab_rails['db_adapter']`
-   and alike. You could just comment all of them out so that we'll just use
-   the defaults.
+1. Edit `/etc/gitlab/gitlab.rb` to use the bundled PostgreSQL. Review all of the
+   settings beginning with `db_` (such as `gitlab_rails['db_adapter']`). To use
+   the default values, you can comment all of them out.
 
 1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
+
 1. Start Unicorn and PostgreSQL so that we can prepare the schema:
 
    ```shell
@@ -110,9 +110,9 @@ need to enable the bundled PostgreSQL:
    sudo gitlab-ctl stop unicorn
    ```
 
-After these steps, you'll have a fresh PostgreSQL database with up-to-date schema.
+After these steps, you have a fresh PostgreSQL database with up-to-date schema.
 
-Next, we'll use `pgloader` to migrate the data from the old MySQL database to the
+Next, use `pgloader` to migrate the data from the old MySQL database to the
 new PostgreSQL one:
 
 1. Save the following snippet in a `commands.load` file, and edit with your
@@ -178,7 +178,7 @@ You can now verify that everything works as expected by visiting GitLab.
 
 ## Source installations
 
-For installations from source that use MySQL, you'll first need to
+For installations from source that use MySQL, you must first
 [install PostgreSQL and create a database](../install/installation.md#6-database).
 
 After the database is created, go on with the following steps:
@@ -211,9 +211,9 @@ After the database is created, go on with the following steps:
    sudo -u git -H bundle exec rake db:create db:migrate RAILS_ENV=production
    ```
 
-After these steps, you'll have a fresh PostgreSQL database with up-to-date schema.
+After these steps, you have a fresh PostgreSQL database with up-to-date schema.
 
-Next, we'll use `pgloader` to migrate the data from the old MySQL database to the
+Next, use `pgloader` to migrate the data from the old MySQL database to the
 new PostgreSQL one:
 
 1. Save the following snippet in a `commands.load` file, and edit with your

doc/update/restore_after_failure.md

@@ -65,7 +65,7 @@ sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
 ```
 
 Once the migration is successfully marked, run the Rake `db:migrate` task again.
-You will likely have to repeat this process several times until all failed
+You might need to repeat this process several times until all failed
 migrations are marked complete.
 
 ### GitLab < 8.6
@@ -86,5 +86,5 @@ exit
 ```
 
 Once the migration is successfully marked, run the Rake `db:migrate` task again.
-You will likely have to repeat this process several times until all failed
+You might need to repeat this process several times until all failed
 migrations are marked complete.

doc/update/upgrading_from_ce_to_ee.md

@@ -128,7 +128,7 @@ sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production
 
 Certain versions of GitLab may require you to perform additional steps when
 upgrading from Community Edition to Enterprise Edition. Should such steps be
-necessary, they will listed per version below.
+necessary, they are listed per version below.
 
 <!--
 Example:

doc/update/upgrading_from_source.md

@@ -8,7 +8,7 @@ comments: false
 # Upgrading Community Edition and Enterprise Edition from source
 
 NOTE:
-Users wishing to upgrade to 12.0.0 will have to take some extra steps. See the
+Users wishing to upgrade to 12.0.0 must take some extra steps. See the
 version specific upgrade instructions for 12.0.0 for more details.
 
 Make sure you view this update guide from the branch (version) of GitLab you
@@ -284,12 +284,12 @@ longer handles setting it.
 
 If you are using Apache instead of NGINX see the updated [Apache templates](https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache).
 Also note that because Apache does not support upstreams behind Unix sockets you
-will need to let GitLab Workhorse listen on a TCP port. You can do this
+must let GitLab Workhorse listen on a TCP port. You can do this
 via [`/etc/default/gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab.default.example#L38).
 
 #### SMTP configuration
 
-If you're installing from source and use SMTP to deliver mail, you will need to
+If you're installing from source and use SMTP to deliver mail, you must
 add the following line to `config/initializers/smtp_settings.rb`:
 
 ```ruby

doc/update/upgrading_postgresql_using_slony.md

@@ -11,12 +11,12 @@ to the latest version without the need for hours of downtime. This guide assumes
 you have two database servers: one database server running an older version of
 PostgreSQL (e.g. 9.2.18) and one server running a newer version (e.g. 9.6.0).
 
-For this process we'll use a PostgreSQL replication tool called
+For this process we use a PostgreSQL replication tool called
 ["Slony"](https://www.slony.info/). Slony allows replication between different
 PostgreSQL versions and as such can be used to upgrade a cluster with a minimal
 amount of downtime.
 
-In various places we'll refer to the user `gitlab-psql`. This user should be the
+In various places we refer to the user `gitlab-psql`. This user should be the
 user used to run the various PostgreSQL OS processes. If you're using a
 different user (e.g. `postgres`) you should replace `gitlab-psql` with the name
 of said user. This guide also assumes your database is called
@@ -28,8 +28,8 @@ change this accordingly.
 Slony only replicates data and not any schema changes. As a result we must
 ensure that all databases have the same database structure.
 
-To do so we'll generate a dump of our current database. This dump will only
-contain the structure, not any data. To generate this dump run the following
+To do so, generate a dump of the current database. This dump only
+contains the structure, not any data. To generate this dump run the following
 command on your active database server:
 
 ```shell
@@ -49,20 +49,20 @@ command on your active database server:
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/pg_dump -h /var/opt/gitlab/postgresql/ -p 5432 -U gitlab-psql -a -t schema_migrations -f /tmp/migrations.sql gitlabhq_production
 ```
 
-Next we'll need to move these files somewhere accessible by the new database
-server. The easiest way is to simply download these files to your local system:
+Next, move these files somewhere accessible by the new database
+server. The easiest way is to download these files to your local system:
 
 ```shell
 scp your-user@production-database-host:/tmp/*.sql /tmp
 ```
 
-This will copy all the SQL files located in `/tmp` to your local system's
+This copies all the SQL files located in `/tmp` to your local system's
 `/tmp` directory. Once copied you can safely remove the files from the database
 server.
 
 ## Installing Slony
 
-Slony will be used to upgrade the database without requiring a long downtime.
+Use Slony to upgrade the database without requiring a long downtime.
 Slony can be downloaded from <https://www.slony.info/>. If you have installed
 PostgreSQL using your operating system's package manager you may also be able to
 install Slony using said package manager.
@@ -94,7 +94,7 @@ test -f /opt/gitlab/embedded/bin/slonik_init_cluster && echo 'Slony Perl tools a
 ```
 
 This assumes Slony was installed to `/opt/gitlab/embedded`. If Slony was
-installed properly the output of these commands will be (the mentioned `slonik`
+installed properly the output of these commands is (the mentioned `slonik`
 version may be different):
 
 ```plaintext
@@ -106,8 +106,8 @@ slonik version 2.2.5
 ## Slony User
 
 Next we must set up a PostgreSQL user that Slony can use to replicate your
-database. To do so, log in to your production database using `psql` using a
-super user account. Once done run the following SQL queries:
+database. To do so, sign in to your production database using `psql` using a
+super-user account. After signing in, run the following SQL queries:
 
 ```sql
 CREATE ROLE slony WITH SUPERUSER LOGIN REPLICATION ENCRYPTED PASSWORD 'password string here';
@@ -115,20 +115,20 @@ ALTER ROLE slony SET statement_timeout TO 0;
 ```
 
 Make sure you replace "password string here" with the actual password for the
-user. A password is *required*. This user must be created on _both_ the old and
+user. A password is required. This user must be created on both the old and
 new database server using the same password.
 
-Once the user has been created make sure you note down the password as we will
-need it later on.
+After creating the user, be sure to note the password, as the password is needed
+later.
 
 ## Configuring Slony
 
-Now we can finally start configuring Slony. Slony uses a configuration file for
-most of the work so we'll need to set this one up. This configuration file
+We can now start configuring Slony. Slony uses a configuration file for
+most of the work so we need to set this one up. This configuration file
 specifies where to put log files, how Slony should connect to the databases,
 etc.
 
-First we'll need to create some required directories and set the correct
+First, create some required directories and set the correct
 permissions. To do so, run the following commands on both the old and new
 database server:
 
@@ -199,8 +199,7 @@ appropriate path to the `psql` executable.
 
 The above command outputs a list of tables in a format that can be copy-pasted
 directly into the above configuration file. Make sure to _replace_ `TABLES` with
-this output, don't just append it below it. Once done you'll end up with
-something like this:
+this output, don't just append it below it. The result looks like this:
 
 ```perl
 "pkeyedtables" => [
@@ -251,14 +250,14 @@ following:
  ... more rows here ...
 ```
 
-Now we can initialize the required tables and what not that Slony will use for
+Now we can initialize the required tables and what not that Slony uses for
 its replication process. To do so, run the following on the old database:
 
 ```shell
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/slonik_init_cluster --conf /var/opt/gitlab/postgresql/slony/slon_tools.conf | /opt/gitlab/embedded/bin/slonik
 ```
 
-If all went well this will produce something along the lines of:
+If all went well this produces something along the lines of:
 
 ```plaintext
 <stdin>:10: Set up replication nodes
@@ -274,7 +273,7 @@ following on the old database:
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/slon_start 1 --conf /var/opt/gitlab/postgresql/slony/slon_tools.conf
 ```
 
-If all went well this will produce output such as:
+If all went well this produces output such as:
 
 ```plaintext
 Invoke slon for node 1 - /opt/gitlab/embedded/bin/slon -p /var/run/slony1/slony_replication_node1.pid -s 1000 -d2  slony_replication 'host=192.168.0.7 dbname=gitlabhq_production user=slony port=5432 password=hieng8ezohHuCeiqu0leeghai4aeyahp' > /var/log/gitlab/slony/node1/gitlabhq_production-2016-10-06.log 2>&1 &
@@ -289,7 +288,7 @@ Next we need to run the following command on the _new_ database server:
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/slon_start 2 --conf /var/opt/gitlab/postgresql/slony/slon_tools.conf
 ```
 
-This will produce similar output if all went well.
+This produces similar output if all went well.
 
 Next we need to tell the new database server what it should replicate. This can
 be done by running the following command on the _new_ database server:
@@ -324,7 +323,7 @@ This should produce the following output:
 <stdin>:6: Subscribed nodes to set 1
 ```
 
-At this point the new database server will start replicating the data of the old
+At this point the new database server starts replicating the data of the old
 database server. This process can take anywhere from a few minutes to hours, if
 not days. Unfortunately Slony itself doesn't really provide a way of knowing
 when the two databases are in sync. To get an estimate of the progress you can
@@ -357,19 +356,19 @@ function main {
 main
 ```
 
-This script will compare the sizes of the old and new database every minute and
+This script compares the sizes of the old and new database every minute and
 print the result to STDOUT as well as logging it to a file. Make sure to replace
 `SLONY_PASSWORD`, `OLD_HOST`, and `NEW_HOST` with the correct values.
 
 ## Stopping Replication
 
-At some point the two databases are in sync. Once this is the case you'll need
-to plan for a few minutes of downtime. This small downtime window is used to
-stop the replication process, remove any Slony data from both databases, restart
-GitLab so it can use the new database, etc.
+At some point, the two databases are in sync. If this is the case, you must plan
+for a few minutes of downtime. This small downtime window is used to stop the
+replication process, remove any Slony data from both databases, and restart
+GitLab so it can use the new database.
 
 First, let's stop all of GitLab. Omnibus users can do so by running the
-following on their GitLab server(s):
+following on their GitLab servers:
 
 ```shell
 sudo gitlab-ctl stop unicorn
@@ -377,14 +376,14 @@ sudo gitlab-ctl stop sidekiq
 sudo gitlab-ctl stop mailroom
 ```
 
-If you have any other processes that use PostgreSQL you should also stop those.
+If you have any other processes that use PostgreSQL, you should also stop those.
 
-Once everything has been stopped you should update any configuration settings,
-DNS records, etc so they all point to the new database.
+After everything has been stopped, be sure to update any configuration settings
+and DNS records so they all point to the new database.
 
-Once the settings have been taken care of we need to stop the replication
-process. It's crucial that no new data is written to the databases at this point
-as this data will be lost.
+When the settings have been taken care of, we need to stop the replication
+process. It's crucial that no new data is written to the databases at this point,
+as this data is discarded.
 
 To stop replication, run the following on both database servers:
 
@@ -392,7 +391,7 @@ To stop replication, run the following on both database servers:
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/slon_kill --conf /var/opt/gitlab/postgresql/slony/slon_tools.conf
 ```
 
-This will stop all the Slony processes on the host the command was executed on.
+This stops all the Slony processes on the host the command was executed on.
 
 ## Resetting Sequences
 
@@ -469,7 +468,7 @@ Upload this script to the _target_ server and execute it as follows:
 bash path/to/the/script/above.sh
 ```
 
-This will correct the ownership of sequences and reset the next value for the
+This corrects the ownership of sequences and reset the next value for the
 `id` column to the next available value.
 
 ## Removing Slony

doc/user/profile/account/two_factor_authentication.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Two-factor authentication (2FA) provides an additional level of security to your
 GitLab account. After being enabled, in addition to supplying your username and
-password to sign in, you'll be prompted for a code generated by your one-time
+password to sign in, you are prompted for a code generated by your one-time
 password authenticator (for example, a password manager on one of your devices).
 
 By enabling 2FA, the only way someone other than you can sign in to your account
@@ -22,20 +22,21 @@ TIP: **Tip:**
 When you enable 2FA, don't forget to back up your [recovery codes](#recovery-codes)!
 
 In addition to time-based one time passwords (TOTP), GitLab supports U2F
-(universal 2nd factor) and WebAuthn (experimental) devices as the second factor of authentication. Once
-enabled, in addition to supplying your username and password to log in, you'll
-be prompted to activate your U2F / WebAuthn device (usually by pressing a button on it),
-and it will perform secure authentication on your behalf.
+(universal 2nd factor) and WebAuthn (experimental) devices as the second factor
+of authentication. After being enabled, in addition to supplying your username
+and password to sign in, you're prompted to activate your U2F / WebAuthn device
+(usually by pressing a button on it) which performs secure authentication on
+your behalf.
 
-It is highly recommended that you set up 2FA with both a
-[one-time password authenticator](#one-time-password) or use [FortiAuthenticator](#one-time-password-via-fortiauthenticator)
-and a [U2F device](#u2f-device) or a [WebAuthn device](#webauthn-device), so you can still access your account
-if you lose your U2F / WebAuthn device.
+It's highly recommended that you set up 2FA with both a [one-time password authenticator](#one-time-password)
+or use [FortiAuthenticator](#one-time-password-via-fortiauthenticator) and a
+[U2F device](#u2f-device) or a [WebAuthn device](#webauthn-device), so you can
+still access your account if you lose your U2F / WebAuthn device.
 
 ## Enabling 2FA
 
-There are multiple ways to enable two-factor authentication: via a one time password authenticator
-or a U2F / WebAuthn device.
+There are multiple ways to enable two-factor authentication: by using a one-time
+password authenticator or a U2F / WebAuthn device.
 
 ### One-time password
 
@@ -62,8 +63,8 @@ To enable 2FA:
       code** field.
    1. Select **Submit**.
 
-If the pin you entered was correct, you'll see a message indicating that
-two-factor authentication has been enabled, and you'll be presented with a list
+If the pin you entered was correct, a message displays indicating that
+two-factor authentication has been enabled, and you're shown a list
 of [recovery codes](#recovery-codes). Be sure to download them and keep them
 in a safe place.
 
@@ -77,7 +78,7 @@ You can use FortiAuthenticator as an OTP provider in GitLab. Users must exist in
 both FortiAuthenticator and GitLab with the exact same username, and users must
 have FortiToken configured in FortiAuthenticator.
 
-You'll also need a username and access token for FortiAuthenticator. The
+You need a username and access token for FortiAuthenticator. The
 `access_token` in the code samples shown below is the FortAuthenticator access
 key. To get the token, see the `REST API Solution Guide` at
 [`Fortinet Document Library`](https://docs.fortinet.com/document/fortiauthenticator/6.2.0/rest-api-solution-guide/158294/the-fortiauthenticator-api).
@@ -170,9 +171,9 @@ To set up 2FA with a U2F device:
 1. Click **Enable Two-Factor Authentication**.
 1. Connect your U2F device.
 1. Click on **Set up New U2F Device**.
-1. A light will start blinking on your device. Activate it by pressing its button.
+1. A light begins blinking on your device. Activate it by pressing its button.
 
-You will see a message indicating that your device was successfully set up.
+A message displays, indicating that your device was successfully set up.
 Click on **Register U2F Device** to complete the process.
 
 ### WebAuthn device
@@ -208,7 +209,7 @@ To set up 2FA with a WebAuthn compatible device:
 1. Select **Set up New WebAuthn Device**.
 1. Depending on your device, you might need to press a button or touch a sensor.
 
-You will see a message indicating that your device was successfully set up.
+A message displays, indicating that your device was successfully set up.
 Recovery codes are not generated for WebAuthn devices.
 
 ## Recovery codes
@@ -219,12 +220,12 @@ Recovery codes are not generated for U2F / WebAuthn devices.
 WARNING:
 Each code can be used only once to log in to your account.
 
-Immediately after successfully enabling two-factor authentication, you'll be
+Immediately after successfully enabling two-factor authentication, you're
 prompted to download a set of generated recovery codes. Should you ever lose access
 to your one-time password authenticator, you can use one of these recovery codes to log in to
 your account. We suggest copying and printing them, or downloading them using
 the **Download codes** button for storage in a safe place. If you choose to
-download them, the file will be called `gitlab-recovery-codes.txt`.
+download them, the file is called `gitlab-recovery-codes.txt`.
 
 If you lose the recovery codes or just want to generate new ones, you can do so
 from the [two-factor authentication account settings page](#regenerate-2fa-recovery-codes) or
@@ -233,8 +234,8 @@ from the [two-factor authentication account settings page](#regenerate-2fa-recov
 ## Logging in with 2FA Enabled
 
 Logging in with 2FA enabled is only slightly different than a normal login.
-Enter your username and password credentials as you normally would, and you'll
-be presented with a second prompt, depending on which type of 2FA you've enabled.
+Enter your username and password credentials as you normally would, and you're
+presented with a second prompt, depending on which type of 2FA you've enabled.
 
 ### Log in via a one-time password
 
@@ -246,19 +247,19 @@ recovery code to log in.
 To log in via a U2F device:
 
 1. Click **Login via U2F Device**.
-1. A light will start blinking on your device. Activate it by touching/pressing
+1. A light begins blinking on your device. Activate it by touching/pressing
    its button.
 
-You will see a message indicating that your device responded to the authentication
-request and you will be automatically logged in.
+A message displays, indicating that your device responded to the authentication
+request, and you're automatically logged in.
 
 ### Log in via WebAuthn device
 
 In supported browsers you should be automatically prompted to activate your WebAuthn device
 (e.g. by touching/pressing its button) after entering your credentials.
 
-You will see a message indicating that your device responded to the authentication
-request and you will be automatically logged in.
+A message displays, indicating that your device responded to the authentication
+request and you're automatically logged in.
 
 ## Disabling 2FA
 
@@ -269,7 +270,7 @@ If you ever need to disable 2FA:
 1. Go to **Account**.
 1. Click **Disable**, under **Two-Factor Authentication**.
 
-This will clear all your two-factor authentication registrations, including mobile
+This clears all your two-factor authentication registrations, including mobile
 applications and U2F / WebAuthn devices.
 
 ## Personal access tokens
@@ -312,7 +313,7 @@ a new set of recovery codes with SSH:
    ssh git@gitlab.example.com 2fa_recovery_codes
    ```
 
-1. You will then be prompted to confirm that you want to generate new codes.
+1. You are prompted to confirm that you want to generate new codes.
    Continuing this process invalidates previously saved codes:
 
    ```shell
@@ -358,13 +359,13 @@ To regenerate 2FA recovery codes, you need access to a desktop browser:
 1. In the **Register Two-Factor Authenticator** pane, click **Regenerate recovery codes**.
 
 NOTE:
-If you regenerate 2FA recovery codes, save them. You won't be able to use any previously created 2FA codes.
+If you regenerate 2FA recovery codes, save them. You can't use any previously created 2FA codes.
 
 ### Ask a GitLab administrator to disable two-factor authentication on your account
 
 If you cannot use a saved recovery code or generate new recovery codes, ask a
 GitLab global administrator to disable two-factor authentication for your
-account. This will temporarily leave your account in a less secure state.
+account. This temporarily leaves your account in a less secure state.
 Sign in and re-enable two-factor authentication as soon as possible.
 
 ## Note to GitLab administrators

doc/user/profile/index.md

@@ -305,7 +305,7 @@ you are asked to sign in again to verify your identity for security reasons.
 NOTE:
 When any session is signed out, or when a session is revoked
 via [Active Sessions](active_sessions.md), all **Remember me** tokens are revoked.
-While other sessions will remain active, the **Remember me** feature will not restore
+While other sessions remain active, the **Remember me** feature doesn't restore
 a session if the browser is closed or the existing session expires.
 
 ### Increased sign-in time

doc/user/profile/notifications.md

@@ -21,7 +21,7 @@ You receive notifications for one of the following reasons:
 While notifications are enabled, you receive notification of actions occurring in that issue, merge request, or epic.
 
 NOTE:
-Notifications can be blocked by an admin, preventing them from being sent.
+Notifications can be blocked by an administrator, preventing them from being sent.
 
 ## Tuning your notifications