From 2d284620e3a81182cf67a783de8f61e9937a5912 Mon Sep 17 00:00:00 2001
From: Catherine Pope <cpope@gitlab.com>
Date: Fri, 25 Nov 2022 08:54:33 +0000
Subject: [PATCH] Cleaned up first person warnings from Vale

---
 .../deployment/composer-npm-deploy.md         |  2 +-
 doc/development/code_review.md                | 44 +++++++++----------
 .../contributing/merge_request_workflow.md    |  2 +-
 .../documentation/topic_types/concept.md      |  2 +-
 doc/development/fe_guide/style/scss.md        |  4 +-
 doc/development/fe_guide/troubleshooting.md   |  4 +-
 .../multi_version_compatibility.md            |  2 +-
 doc/development/projections.md                |  2 +-
 .../testing_guide/end_to_end/index.md         |  8 ++--
 .../testing_guide/frontend_testing.md         |  4 +-
 .../uploads/working_with_uploads.md           | 10 ++---
 .../elasticsearch_troubleshooting.md          | 12 ++---
 doc/topics/authentication/index.md            |  2 +-
 .../dependency_scanning/index.md              |  2 +-
 doc/user/application_security/index.md        |  2 +-
 doc/user/profile/active_sessions.md           |  2 +-
 doc/user/profile/index.md                     |  4 +-
 doc/user/upgrade_email_bypass.md              |  6 +--
 18 files changed, 57 insertions(+), 57 deletions(-)

diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index a603207aef7e8..533b6519d9a10 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -120,7 +120,7 @@ Therefore, for a production environment we use additional steps to ensure that a
 
 ## Where to go next
 
-Since this was a WordPress project, I gave real life code snippets. Some further ideas you can pursue:
+Since this was a WordPress project, it includes real code snippets. Some further ideas you can pursue:
 
 - Having a slightly different script for the default branch allows you to deploy to a production server from that branch and to a stage server from any other branches.
 - Instead of pushing it live, you can push it to WordPress official repository.
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 25cd95a6f04c3..209e971c95267 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -185,49 +185,49 @@ Using checklists improves quality in software engineering. This checklist is a s
 
 See the [test engineering process](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/test-engineering/) for further quality guidelines.
 
-1. I have self-reviewed this MR per [code review guidelines](code_review.md).
-1. For the code that this change impacts, I believe that the automated tests ([Testing Guide](testing_guide/index.md)) validate functionality that is highly important to users (including consideration of [all test levels](testing_guide/testing_levels.md)).
-1. If the existing automated tests do not cover the above functionality, I have added the necessary additional tests or added an issue to describe the automation testing gap and linked it to this MR.
-1. I have considered the technical aspects of this change's impact on GitLab.com hosted customers and self-managed customers.
-1. I have considered the impact of this change on the frontend, backend, and database portions of the system where appropriate and applied the `~ux`, `~frontend`, `~backend`, and `~database` labels accordingly.
-1. I have tested this MR in [all supported browsers](../install/requirements.md#supported-web-browsers), or determined that this testing is not needed.
-1. I have confirmed that this change is [backwards compatible across updates](multi_version_compatibility.md), or I have decided that this does not apply.
-1. I have properly separated EE content from FOSS, or this MR is FOSS only.
+1. You have self-reviewed this MR per [code review guidelines](code_review.md).
+1. For the code that this change impacts, you believe that the automated tests ([Testing Guide](testing_guide/index.md)) validate functionality that is highly important to users (including consideration of [all test levels](testing_guide/testing_levels.md)).
+1. If the existing automated tests do not cover the above functionality, you have added the necessary additional tests or added an issue to describe the automation testing gap and linked it to this MR.
+1. You have considered the technical aspects of this change's impact on GitLab.com hosted customers and self-managed customers.
+1. You have considered the impact of this change on the frontend, backend, and database portions of the system where appropriate and applied the `~ux`, `~frontend`, `~backend`, and `~database` labels accordingly.
+1. You have tested this MR in [all supported browsers](../install/requirements.md#supported-web-browsers), or determined that this testing is not needed.
+1. You have confirmed that this change is [backwards compatible across updates](multi_version_compatibility.md), or you have decided that this does not apply.
+1. You have properly separated EE content from FOSS, or this MR is FOSS only.
     - [Where should EE code go?](ee_features.md)
-1. I have considered that existing data may be surprisingly varied. For example, a new model validation can break existing records. Consider making validation on existing data optional rather than required if you haven't confirmed that existing data will pass validation.
+1. You have considered that existing data may be surprisingly varied. For example, a new model validation can break existing records. Consider making validation on existing data optional rather than required if you haven't confirmed that existing data will pass validation.
 
 ##### Performance, reliability, and availability
 
-1. I am confident that this MR does not harm performance, or I have asked a reviewer to help assess the performance impact. ([Merge request performance guidelines](merge_request_performance_guidelines.md))
-1. I have added [information for database reviewers in the MR description](database_review.md#required), or I have decided that it is unnecessary.
+1. You are confident that this MR does not harm performance, or you have asked a reviewer to help assess the performance impact. ([Merge request performance guidelines](merge_request_performance_guidelines.md))
+1. You have added [information for database reviewers in the MR description](database_review.md#required), or you have decided that it is unnecessary.
     - [Does this MR have database-related changes?](database_review.md)
-1. I have considered the availability and reliability risks of this change.
-1. I have considered the scalability risk based on future predicted growth.
-1. I have considered the performance, reliability, and availability impacts of this change on large customers who may have significantly more data than the average customer.
+1. You have considered the availability and reliability risks of this change.
+1. You have considered the scalability risk based on future predicted growth.
+1. You have considered the performance, reliability, and availability impacts of this change on large customers who may have significantly more data than the average customer.
 
 ##### Observability instrumentation
 
-1. I have included enough instrumentation to facilitate debugging and proactive performance improvements through observability.
+1. You have included enough instrumentation to facilitate debugging and proactive performance improvements through observability.
    See [example](https://gitlab.com/gitlab-org/gitlab/-/issues/346124#expectations) of adding feature flags, logging, and instrumentation.
 
 ##### Documentation
 
-1. I have included changelog trailers, or I have decided that they are not needed.
+1. You have included changelog trailers, or you have decided that they are not needed.
     - [Does this MR need a changelog?](changelog.md#what-warrants-a-changelog-entry)
-1. I have added/updated documentation or decided that documentation changes are unnecessary for this MR.
+1. You have added/updated documentation or decided that documentation changes are unnecessary for this MR.
     - [Is documentation required?](https://about.gitlab.com/handbook/product/ux/technical-writing/workflow/#when-documentation-is-required)
 
 ##### Security
 
-1. I have confirmed that if this MR contains changes to processing or storing of credentials or tokens, authorization, and authentication methods, or other items described in [the security review guidelines](https://about.gitlab.com/handbook/security/#when-to-request-a-security-review), I have added the `~security` label and I have `@`-mentioned `@gitlab-com/gl-security/appsec`.
-1. I have reviewed the documentation regarding [internal application security reviews](https://about.gitlab.com/handbook/security/#internal-application-security-reviews) for **when** and **how** to request a security review and requested a security review if this is warranted for this change.
+1. You have confirmed that if this MR contains changes to processing or storing of credentials or tokens, authorization, and authentication methods, or other items described in [the security review guidelines](https://about.gitlab.com/handbook/security/#when-to-request-a-security-review), you have added the `~security` label and you have `@`-mentioned `@gitlab-com/gl-security/appsec`.
+1. You have reviewed the documentation regarding [internal application security reviews](https://about.gitlab.com/handbook/security/#internal-application-security-reviews) for **when** and **how** to request a security review and requested a security review if this is warranted for this change.
 
 ##### Deployment
 
-1. I have considered using a feature flag for this change because the change may be high risk.
-1. If I am using a feature flag, I plan to test the change in staging before I test it in production, and I have considered rolling it out to a subset of production customers before rolling it out to all customers.
+1. You have considered using a feature flag for this change because the change may be high risk.
+1. If you are using a feature flag, you plan to test the change in staging before you test it in production, and you have considered rolling it out to a subset of production customers before rolling it out to all customers.
     - [When to use a feature flag](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags)
-1. I have informed the Infrastructure department of a default setting or new setting change per [definition of done](contributing/merge_request_workflow.md#definition-of-done), or decided that this is unnecessary.
+1. You have informed the Infrastructure department of a default setting or new setting change per [definition of done](contributing/merge_request_workflow.md#definition-of-done), or decided that this is unnecessary.
 
 ### The responsibility of the merge request author
 
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index f2c06e289c95d..247383d1f39a7 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -313,7 +313,7 @@ The following items are checked after the merge request has been merged:
 1. Confirmed to be working in staging before implementing the change in production, where possible.
 1. Confirmed to be working in the production with no new [Sentry](https://about.gitlab.com/handbook/engineering/monitoring/#sentry) errors after the contribution is deployed.
 1. Confirmed that the [rollout plan](https://about.gitlab.com/handbook/engineering/development/processes/rollout-plans/) has been completed.
-1. If there is a performance risk in the change, I have analyzed the performance of the system before and after the change.
+1. If there is a performance risk in the change, you have analyzed the performance of the system before and after the change.
 1. *If the merge request uses feature flags, per-project or per-group enablement, and a staged rollout:*
    - Confirmed to be working on GitLab projects.
    - Confirmed to be working at each stage for all projects added.
diff --git a/doc/development/documentation/topic_types/concept.md b/doc/development/documentation/topic_types/concept.md
index 7be6bef4fadaa..e01b06c2c0723 100644
--- a/doc/development/documentation/topic_types/concept.md
+++ b/doc/development/documentation/topic_types/concept.md
@@ -11,7 +11,7 @@ A concept introduces a single feature or concept.
 A concept should answer the questions:
 
 - What is this?
-- Why would I use it?
+- Why would you use it?
 
 Think of everything someone might want to know if they've never heard of this concept before.
 
diff --git a/doc/development/fe_guide/style/scss.md b/doc/development/fe_guide/style/scss.md
index 98f74813231ff..c20ade6bc1d5e 100644
--- a/doc/development/fe_guide/style/scss.md
+++ b/doc/development/fe_guide/style/scss.md
@@ -41,13 +41,13 @@ GitLab differs from the scale used in the Bootstrap library. For a Bootstrap pad
 utility, you may need to double the size of the applied utility to achieve the same visual
 result (such as `ml-1` becoming `gl-ml-2`).
 
-#### Where should I put new utility classes?
+#### Where should you put new utility classes?
 
 If a class you need has not been added to GitLab UI, you get to add it! Follow the naming patterns documented in the [utility files](https://gitlab.com/gitlab-org/gitlab-ui/-/tree/main/src/scss/utility-mixins) and refer to [GitLab UI's CSS documentation](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/doc/contributing/adding_css.md#adding-utility-mixins) for more details, especially about adding responsive and stateful rules.
 
 If it is not possible to wait for a GitLab UI update (generally one day), add the class to [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/stylesheets/utilities.scss) following the same naming conventions documented in GitLab UI. A follow-up issue to backport the class to GitLab UI and delete it from GitLab should be opened.
 
-#### When should I create component classes?
+#### When should you create component classes?
 
 We recommend a "utility-first" approach.
 
diff --git a/doc/development/fe_guide/troubleshooting.md b/doc/development/fe_guide/troubleshooting.md
index 873a14b8f1483..3e4c5007b6426 100644
--- a/doc/development/fe_guide/troubleshooting.md
+++ b/doc/development/fe_guide/troubleshooting.md
@@ -10,13 +10,13 @@ Running into a problem? Maybe this will help ¯\＿(ツ)＿/¯.
 
 ## Troubleshooting issues
 
-### This guide doesn't contain the issue I ran into
+### This guide doesn't contain the issue you ran into
 
 If you run into a Frontend development issue that is not in this guide, consider updating this guide with your issue and possible remedies. This way future adventurers can face these dragons with more success, being armed with your experience and knowledge.
 
 ## Testing issues
 
-### ``Property or method `nodeType` is not defined`` but I'm not using `nodeType` anywhere
+### ``Property or method `nodeType` is not defined`` but you're not using `nodeType` anywhere
 
 This issue can happen in Vue component tests, when an expectation fails, but there is an error thrown when
 Jest tries to pretty print the diff in the console. It's been noted that using `toEqual` with an array as a
diff --git a/doc/development/multi_version_compatibility.md b/doc/development/multi_version_compatibility.md
index 8e2103b2f3ec7..36b392a00373e 100644
--- a/doc/development/multi_version_compatibility.md
+++ b/doc/development/multi_version_compatibility.md
@@ -112,7 +112,7 @@ During an update, there will be [two different versions of GitLab running in dif
 
 Yes! We have specific instructions for [zero-downtime updates](../update/index.md#upgrading-without-downtime) because it allows us to ignore some permutations of compatibility. This is why we don't worry about Rails code making DB calls to an old PostgreSQL database schema.
 
-## I've identified a potential backwards compatibility problem, what can I do about it?
+## You've identified a potential backwards compatibility problem, what can you do about it?
 
 ### Coordinate
 
diff --git a/doc/development/projections.md b/doc/development/projections.md
index e45a16c267d9a..49480981d8d01 100644
--- a/doc/development/projections.md
+++ b/doc/development/projections.md
@@ -20,7 +20,7 @@ Projections are a way to define relations between files. Every file can have a
 You can find a basic list of projection options in
 [projectionist.txt](https://github.com/tpope/vim-projectionist/blob/master/doc/projectionist.txt)
 
-## Which plugins can I use
+## Which plugins can you use
 
 - vim
   - [vim-projectionist](https://github.com/tpope/vim-projectionist)
diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index 8ffe044c4d8bd..55d725ba4ae1e 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -238,7 +238,7 @@ Each type of scheduled pipeline generates a static link for the latest test repo
 - [`production`](https://storage.googleapis.com/gitlab-qa-allure-reports/production-full/master/index.html)
 - [`production-sanity`](https://storage.googleapis.com/gitlab-qa-allure-reports/production-sanity/master/index.html)
 
-## How do I run the tests?
+## How do you run the tests?
 
 If you are not [testing code in a merge request](#testing-code-in-merge-requests),
 there are two main options for running the tests. If you want to run
@@ -255,12 +255,12 @@ and the section below.
 
 Learn how to perform [tests that require special setup or consideration to run on your local environment](running_tests_that_require_special_setup.md).
 
-## How do I write tests?
+## How do you write tests?
 
 In order to write new tests, you first need to learn more about GitLab QA
 architecture. See the [documentation about it](https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/architecture.md).
 
-Once you decided where to put [test environment orchestration scenarios](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/lib/gitlab/qa/scenario) and
+After you've decided where to put [test environment orchestration scenarios](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/lib/gitlab/qa/scenario) and
 [instance-level scenarios](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/specs/features), take a look at the [GitLab QA README](https://gitlab.com/gitlab-org/gitlab/-/tree/master/qa/README.md),
 the [GitLab QA orchestrator README](https://gitlab.com/gitlab-org/gitlab-qa/tree/master/README.md),
 and [the already existing instance-level scenarios](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/specs/features).
@@ -283,7 +283,7 @@ Continued reading:
 - [Execution context selection](execution_context_selection.md)
 - [Troubleshooting](troubleshooting.md)
 
-## Where can I ask for help?
+## Where can you ask for help?
 
 You can ask question in the `#quality` channel on Slack (GitLab internal) or
 you can find an issue you would like to work on in
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index 041b0f0a4f40f..56bbcb815d185 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -90,7 +90,7 @@ function getFahrenheit(celsius) {
 }
 ```
 
-It does not make sense to test our `getFahrenheit` function because underneath it does nothing else but invoking the library function, and we can expect that one is working as intended. (Simplified, I know)
+It does not make sense to test our `getFahrenheit` function because underneath it does nothing else but invoking the library function, and we can expect that one is working as intended.
 
 Let's take a short look into Vue land. Vue is a critical part of the GitLab JavaScript codebase. When writing specs for Vue components, a common gotcha is to actually end up testing Vue provided functionality, because it appears to be the easiest thing to test. Here's an example taken from our codebase.
 
@@ -713,7 +713,7 @@ unit testing by mocking out modules that cannot be easily consumed in our test e
 > Instead, consider using [`jest.mock(..)`](https://jestjs.io/docs/jest-object#jestmockmodulename-factory-options)
 > (or a similar mocking function) in the relevant spec file.
 
-#### Where should I put manual mocks?
+#### Where should you put manual mocks?
 
 Jest supports [manual module mocks](https://jestjs.io/docs/manual-mocks) by placing a mock in a `__mocks__/` directory next to the source module
 (for example, `app/assets/javascripts/ide/__mocks__`). **Don't do this.** We want to keep all of our test-related code in one place (the `spec/` folder).
diff --git a/doc/development/uploads/working_with_uploads.md b/doc/development/uploads/working_with_uploads.md
index c88762e6bd5b7..92d0f45bd4baa 100644
--- a/doc/development/uploads/working_with_uploads.md
+++ b/doc/development/uploads/working_with_uploads.md
@@ -8,9 +8,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## Recommendations
 
-- When creating an uploader, [make it a subclass](#where-should-i-store-my-files) of `AttachmentUploader`
+- When creating an uploader, [make it a subclass](#where-should-you-store-your-files) of `AttachmentUploader`
 - Add your uploader to the [tables](#tables) in this document
-- Do not add [new object storage buckets](#where-should-i-store-my-files)
+- Do not add [new object storage buckets](#where-should-you-store-your-files)
 - Implement [direct upload](#implementing-direct-upload-support)
 - If you need to process your uploads, decide [where to do that](#processing-uploads)
 
@@ -19,7 +19,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 - [CarrierWave Uploaders](#carrierwave-uploaders)
 - [GitLab modifications to CarrierWave](#gitlab-modifications-to-carrierwave)
 
-## Where should I store my files?
+## Where should you store your files?
 
 CarrierWave Uploaders determine where files get
 stored. When you create a new Uploader class you are deciding where to store the files of your new
@@ -169,8 +169,8 @@ class Project < ApplicationRecord
 end
 ```
 
-Now if I upload an avatar called `tanuki.png` the idea is that in the
-`projects.avatar` column for my project, CarrierWave stores the string
+Now if you upload an avatar called `tanuki.png` the idea is that in the
+`projects.avatar` column for your project, CarrierWave stores the string
 `tanuki.png`, and that the AttachmentUploader class contains the
 configuration data and directory schema. For example if the project ID
 is 123, the actual file may be in
diff --git a/doc/integration/advanced_search/elasticsearch_troubleshooting.md b/doc/integration/advanced_search/elasticsearch_troubleshooting.md
index 11d8ad0a59626..5833b6667c6d2 100644
--- a/doc/integration/advanced_search/elasticsearch_troubleshooting.md
+++ b/doc/integration/advanced_search/elasticsearch_troubleshooting.md
@@ -96,7 +96,7 @@ Here are some common pitfalls and how to overcome them.
   a Lucene index.
 - **Replicas**: Failover mechanisms that duplicate indices.
 
-## How can I verify that my GitLab instance is using Elasticsearch?
+## How can you verify that your GitLab instance is using Elasticsearch?
 
 There are a couple of ways to achieve that:
 
@@ -184,13 +184,13 @@ If reindexing the project shows:
 - Elasticsearch errors or doesn't present any errors at all, reach out to your
   Elasticsearch administrator to check the instance.
 
-### I updated GitLab and now I can't find anything
+### You updated GitLab and now you can't find anything
 
 We continuously make updates to our indexing strategies and aim to support
 newer versions of Elasticsearch. When indexing changes are made, it may
 be necessary for you to [reindex](elasticsearch.md#zero-downtime-reindexing) after updating GitLab.
 
-### I indexed all the repositories but I can't get any hits for my search term in the UI
+### You indexed all the repositories but you can't get any hits for your search term in the UI
 
 Make sure you [indexed all the database data](elasticsearch.md#enable-advanced-search).
 
@@ -220,7 +220,7 @@ The above instructions are not to be used for scenarios that only index a [subse
 
 See [Elasticsearch Index Scopes](elasticsearch.md#advanced-search-index-scopes) for more information on searching for specific types of data.
 
-### I indexed all the repositories but then switched Elasticsearch servers and now I can't find anything
+### You indexed all the repositories but then switched Elasticsearch servers and now you can't find anything
 
 You must re-run all the Rake tasks to reindex the database, repositories, and wikis.
 
@@ -228,11 +228,11 @@ You must re-run all the Rake tasks to reindex the database, repositories, and wi
 
 The more data present in your GitLab instance, the longer the indexing process takes.
 
-### There are some projects that weren't indexed, but I don't know which ones
+### There are some projects that weren't indexed, but you don't know which ones
 
 You can run `sudo gitlab-rake gitlab:elastic:projects_not_indexed` to display projects that aren't indexed.
 
-### No new data is added to the Elasticsearch index when I push code
+### No new data is added to the Elasticsearch index when you push code
 
 NOTE:
 This was [fixed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35936) in GitLab 13.2 and the Rake task is not available for versions greater than that.
diff --git a/doc/topics/authentication/index.md b/doc/topics/authentication/index.md
index 12ff5cb50b8bc..763e16bc31dd0 100644
--- a/doc/topics/authentication/index.md
+++ b/doc/topics/authentication/index.md
@@ -12,7 +12,7 @@ This page gathers all the resources for the topic **Authentication** within GitL
 
 - [SSH](../../user/ssh.md)
 - [Two-factor authentication](../../user/profile/account/two_factor_authentication.md)
-- [Why do I keep getting signed out?](../../user/profile/index.md#why-do-i-keep-getting-signed-out)
+- [Why do you keep getting signed out?](../../user/profile/index.md#why-do-you-keep-getting-signed-out)
 - **Articles:**
   - [Support for Universal 2nd Factor Authentication - YubiKeys](https://about.gitlab.com/blog/2016/06/22/gitlab-adds-support-for-u2f/)
   - [Security Webcast with Yubico](https://about.gitlab.com/blog/2016/08/31/gitlab-and-yubico-security-webcast/)
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 4ed9ceedb4de4..2c0b762345d57 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -1257,7 +1257,7 @@ file in the `CI_BUILDS_DIR` directory triggers the dependency scanning job.
 
 We recommend committing the lock files, which prevents this warning.
 
-### I no longer get the latest Docker image after setting `DS_MAJOR_VERSION` or `DS_ANALYZER_IMAGE`
+### You no longer get the latest Docker image after setting `DS_MAJOR_VERSION` or `DS_ANALYZER_IMAGE`
 
 If you have manually set `DS_MAJOR_VERSION` or `DS_ANALYZER_IMAGE` for specific reasons,
 and now must update your configuration to again get the latest patched versions of our
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index f92eee83c74d4..22965fb6bbbf2 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -683,7 +683,7 @@ This can be used for offline setups or for anyone wishing to use [Auto DevOps](.
 
 Instructions are available in the [legacy template project](https://gitlab.com/gitlab-org/auto-devops-v12-10).
 
-#### Vulnerabilities are found, but the job succeeds. How can I have a pipeline fail instead?
+#### Vulnerabilities are found, but the job succeeds. How can you have a pipeline fail instead?
 
 In these circumstances, that the job succeeds is the default behavior. The job's status indicates
 success or failure of the analyzer itself. Analyzer results are displayed in the
diff --git a/doc/user/profile/active_sessions.md b/doc/user/profile/active_sessions.md
index 430d1c3dc9fdb..7a837258cb226 100644
--- a/doc/user/profile/active_sessions.md
+++ b/doc/user/profile/active_sessions.md
@@ -40,7 +40,7 @@ To revoke an active session:
 
 NOTE:
 When any session is revoked all **Remember me** tokens for all
-devices are revoked. See [Why do I keep getting signed out?](index.md#why-do-i-keep-getting-signed-out)
+devices are revoked. See [Why do you keep getting signed out?](index.md#why-do-you-keep-getting-signed-out)
 for more information about the **Remember me** feature.
 
 <!-- ## Troubleshooting
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index 4adf6c351df7e..d6c5bd6c1082c 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -328,7 +328,7 @@ To view a user's activity in a top-level Activity view:
 
 ## Troubleshooting
 
-### Why do I keep getting signed out?
+### Why do you keep getting signed out?
 
 When you sign in to the main GitLab application, a `_gitlab_session` cookie is
 set. When you close your browser, the cookie is cleared client-side
@@ -368,7 +368,7 @@ GitLab uses both session and persistent cookies:
 
 - Session cookie: Session cookies are normally removed at the end of the browser session when
   the browser is closed. The `_gitlab_session` cookie has no fixed expiration date. However,
-  it expires based on its [`session_expire_delay`](#why-do-i-keep-getting-signed-out).
+  it expires based on its [`session_expire_delay`](#why-do-you-keep-getting-signed-out).
 - Persistent cookie: The `remember_user_token` is a cookie with an expiration date of two weeks.
   GitLab activates this cookie if you select **Remember Me** when you sign in.
 
diff --git a/doc/user/upgrade_email_bypass.md b/doc/user/upgrade_email_bypass.md
index ef58d8aec6688..afbdcbcdf099a 100644
--- a/doc/user/upgrade_email_bypass.md
+++ b/doc/user/upgrade_email_bypass.md
@@ -76,7 +76,7 @@ Your primary email address is not confirmed.
 You can assure your users that they have not been [Blocked](admin_area/moderate_users.md#block-and-unblock-users) by an administrator.
 When affected users see this message, they must confirm their email address before they can commit code.
 
-## What do I need to know as an administrator of a GitLab self-managed Instance?
+## What do you need to know as an administrator of a GitLab self-managed Instance?
 
 You have the following options to help your users:
 
@@ -85,7 +85,7 @@ You have the following options to help your users:
 
 As an administrator, you may also confirm a user in the [Admin Area](admin_area/index.md#administering-users).
 
-## What do I do if I am an administrator and I am locked out?
+## What do you do if you are an administrator and you're locked out?
 
 If you are an administrator and cannot otherwise verify your email address, sign in to your GitLab
 instance with a [Rails console session](../administration/operations/rails_console.md#starting-a-rails-console-session).
@@ -97,7 +97,7 @@ admin.confirmed_at = Time.zone.now
 admin.save!
 ```
 
-## How do I force-confirm all users on my self-managed instance?
+## How do you force-confirm all users on your self-managed instance?
 
 If you are an administrator and would like to force-confirm all users on your system, sign in to your GitLab
 instance with a [Rails console session](../administration/operations/rails_console.md#starting-a-rails-console-session).
-- 
GitLab