Made merge request lowercase

We are inconsistent with lowercase for merge requests
and our style guide recommends lowercase:
https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html\#merge-requests

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -818,7 +818,7 @@ conflicting_permanent_redirects = RedirectRoute.matching_path_and_descendants(pa
 conflicting_permanent_redirects.destroy_all
 ```
 
-## Merge Requests
+## Merge requests
 
 ### Close a merge request properly (if merged but still marked as open)
 

doc/api/commits.md

@@ -740,9 +740,9 @@ Example response:
 }
 ```
 
-## List Merge Requests associated with a commit
+## List merge requests associated with a commit
 
-Get a list of Merge Requests related to the specified commit.
+Get a list of merge requests related to the specified commit.
 
 ```plaintext
 GET /projects/:id/repository/commits/:sha/merge_requests

doc/api/merge_request_approvals.md

@@ -527,9 +527,9 @@ DELETE /projects/:id/approval_rules/:approval_rule_id
 | `id`                 | integer or string | yes      | The ID or [URL-encoded path of a project](index.md#namespaced-path-encoding) |
 | `approval_rule_id`   | integer | yes      | The ID of a approval rule
 
-## Merge Request-level MR approvals
+## Merge request-level MR approvals
 
-Configuration for approvals on a specific Merge Request. Must be authenticated for all endpoints.
+Configuration for approvals on a specific merge request. Must be authenticated for all endpoints.
 
 ### Get Configuration
 
@@ -957,7 +957,7 @@ These are system generated rules.
 | `merge_request_iid` | integer | yes      | The IID of the merge request |
 | `approval_rule_id`  | integer | yes      | The ID of an approval rule |
 
-## Approve Merge Request
+## Approve merge request
 
 > Moved to GitLab Premium in 13.9.
 
@@ -1020,7 +1020,7 @@ does not match, the response code is `409`.
 }
 ```
 
-## Unapprove Merge Request
+## Unapprove merge request
 
 > Moved to GitLab Premium in 13.9.
 

doc/api/merge_requests.md

@@ -2686,7 +2686,7 @@ Example response:
 
 ## Approvals
 
-For approvals, see [Merge Request Approvals](merge_request_approvals.md)
+For approvals, see [Merge request approvals](merge_request_approvals.md)
 
 ## List merge request state events
 

doc/api/notes.md

@@ -320,7 +320,7 @@ Parameters:
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/snippets/52/notes/1659"
 ```
 
-## Merge Requests
+## Merge requests
 
 ### List all merge request notes
 

doc/api/projects.md

@@ -1449,7 +1449,7 @@ Supported attributes:
 | `wiki_access_level`                                         | string         | **{dotted-circle}** No | One of `disabled`, `private`, or `enabled`. |
 | `wiki_enabled`                                              | boolean        | **{dotted-circle}** No | _(Deprecated)_ Enable wiki for this project. Use `wiki_access_level` instead. |
 | `issues_template` **(PREMIUM)**                             | string         | **{dotted-circle}** No | Default description for Issues. Description is parsed with GitLab Flavored Markdown. See [Templates for issues and merge requests](#templates-for-issues-and-merge-requests). |
-| `merge_requests_template` **(PREMIUM)**                     | string         | **{dotted-circle}** No | Default description for Merge Requests. Description is parsed with GitLab Flavored Markdown. See [Templates for issues and merge requests](#templates-for-issues-and-merge-requests). |
+| `merge_requests_template` **(PREMIUM)**                     | string         | **{dotted-circle}** No | Default description for merge requests. Description is parsed with GitLab Flavored Markdown. See [Templates for issues and merge requests](#templates-for-issues-and-merge-requests). |
 | `keep_latest_artifact`                                      | boolean        | **{dotted-circle}** No | Disable or enable the ability to keep the latest artifact for this project. |
 | `mr_default_target_self`                                    | boolean        | **{dotted-circle}** No | For forked projects, target merge requests to this project. If `false`, the target will be the upstream project. |
 

doc/api/users.md

@@ -1838,7 +1838,7 @@ The activities that update the timestamp are:
 
 - Git HTTP/SSH activities (such as clone, push)
 - User logging in to GitLab
-- User visiting pages related to Dashboards, Projects, Issues, and Merge Requests ([introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54947) in GitLab 11.8)
+- User visiting pages related to dashboards, projects, issues, and merge requests ([introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54947) in GitLab 11.8)
 - User using the API
 - User using the GraphQL API
 

doc/api/visual_review_discussions.md

@@ -10,7 +10,7 @@ type: reference, api
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18710) in GitLab 12.5.
 > - [Moved](https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-subscription-model/) to GitLab Premium in 13.9.
 
-Visual Review discussions are notes on Merge Requests sent as
+Visual Review discussions are notes on merge requests sent as
 feedback from [Visual Reviews](../ci/review_apps/index.md#visual-reviews).
 
 ## Create new merge request thread

doc/architecture/blueprints/consolidating_groups_and_projects/index.md

@@ -131,7 +131,7 @@ epic.
 
 The initial iteration will provide a framework to house features under `Namespaces`. Stage groups will eventually need to migrate their own features and functionality over to `Namespaces`. This may impact these features in unexpected ways. Therefore, to minimize UX debt and maintain product consistency, stage groups will have to consider a number of factors when migrating their features over to `Namespaces`:
 
-1. **Conceptual model**: What are the current and future state conceptual models of these features ([see object modeling for designers](https://hpadkisson.medium.com/object-modeling-for-designers-an-introduction-7871bdcf8baf))? These should be documented in Pajamas (example: [Merge Requests](https://design.gitlab.com/objects/merge-request)).
+1. **Conceptual model**: What are the current and future state conceptual models of these features ([see object modeling for designers](https://hpadkisson.medium.com/object-modeling-for-designers-an-introduction-7871bdcf8baf))? These should be documented in Pajamas (example: [merge requests](https://design.gitlab.com/objects/merge-request)).
 1. **Merge conflicts**: What inconsistencies are there across project, group, and admin levels? How might these be addressed? For an example of how we rationalized this for labels, please see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338820).
 1. **Inheritance & information flow**: How is information inherited across our container hierarchy currently? How might this be impacted if complying with the new [inheritance behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/343316) framework?
 1. **Settings**: Where can settings for this feature be found currently? How will these be impacted by `Namespaces`?

doc/architecture/blueprints/database_testing/index.md

@@ -100,7 +100,7 @@ The short-term goal is detailed in [this epic](https://gitlab.com/groups/gitlab-
 
 ### Mid-term - Improved feedback, query testing and background migration testing
 
-Mid-term, we plan to expand the level of detail the testing pipeline reports back to the Merge Request and expand its scope to cover query testing, too. By doing so, we use our experience from database code reviews and using thin-clone technology and bring this back closer to the GitLab workflow. Instead of reaching out to different tools (`postgres.ai`, `joe`, Slack, plan visualizations, and so on) we bring this back to GitLab and working directly on the Merge Request.
+Mid-term, we plan to expand the level of detail the testing pipeline reports back to the merge requet and expand its scope to cover query testing, too. By doing so, we use our experience from database code reviews and using thin-clone technology and bring this back closer to the GitLab workflow. Instead of reaching out to different tools (`postgres.ai`, `joe`, Slack, plan visualizations, and so on) we bring this back to GitLab and working directly on the merge request.
 
 Secondly, we plan to cover background migrations testing, too. These are typically data migrations that are scheduled to run over a long period of time. The success of both the scheduling phase and the job execution phase typically depends a lot on data distribution - which only surfaces when running these migrations on actual production data. In order to become confident about a background migration, we plan to provide the following feedback:
 
@@ -109,7 +109,7 @@ Secondly, we plan to cover background migrations testing, too. These are typical
 
 ### Long-term - incorporate into GitLab product
 
-There are opportunities to discuss for extracting features from this into GitLab itself. For example, annotating the Merge Request with query examples and attaching feedback gathered from the testing run can become a first-class citizen instead of using Merge Request description and comments for it. We plan to evaluate those ideas as we see those being used in earlier phases and bring our experience back into the product.
+There are opportunities to discuss for extracting features from this into GitLab itself. For example, annotating the merge request with query examples and attaching feedback gathered from the testing run can become a first-class citizen instead of using merge request description and comments for it. We plan to evaluate those ideas as we see those being used in earlier phases and bring our experience back into the product.
 
 ## An alternative discussed: Anonymization
 

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -378,7 +378,7 @@ Now, we would need to deploy our app by running `envoy run deploy`, but it won't
 
 Now it's time to commit [Envoy.blade.php](https://gitlab.com/mehranrasulian/laravel-sample/blob/master/Envoy.blade.php) and push it to the `main` branch.
 To keep things simple, we commit directly to `main`, without using [feature-branches](../../../topics/gitlab_flow.md#github-flow-as-a-simpler-alternative) since collaboration is beyond the scope of this tutorial.
-In a real world project, teams may use [Issue Tracker](../../../user/project/issues/index.md) and [Merge Requests](../../../user/project/merge_requests/index.md) to move their code across branches:
+In a real world project, teams may use [Issue Tracker](../../../user/project/issues/index.md) and [merge requests](../../../user/project/merge_requests/index.md) to move their code across branches:
 
 ```shell
 git add Envoy.blade.php

doc/ci/index.md

@@ -64,7 +64,7 @@ GitLab CI/CD supports numerous configuration options:
 | [Git submodules for CI/CD](git_submodules.md)                                           | Configure jobs for using Git submodules.                                                  |
 | [SSH keys for CI/CD](ssh_keys/index.md)                                                 | Using SSH keys in your CI pipelines.                                                      |
 | [Pipeline triggers](triggers/index.md)                                                  | Trigger pipelines through the API.                                                        |
-| [Pipelines for Merge Requests](pipelines/merge_request_pipelines.md)                    | Design a pipeline structure for running a pipeline in merge requests.                     |
+| [Pipelines for merge requests](pipelines/merge_request_pipelines.md)                    | Design a pipeline structure for running a pipeline in merge requests.                     |
 | [Integrate with Kubernetes clusters](../user/infrastructure/clusters/index.md)                 | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. |
 | [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories.                                   |
 | [`.gitlab-ci.yml` full reference](yaml/index.md)                                        | All the attributes you can use with GitLab CI/CD.                                         |

doc/ci/migration/jenkins.md

@@ -196,7 +196,7 @@ can leverage. You can see the complete list of packaging features in the
 
 Where you may have used plugins to get things like code quality, unit tests, security scanning, and so on working in Jenkins,
 GitLab takes advantage of our connected ecosystem to automatically pull these kinds of results into
-your Merge Requests, pipeline details pages, and other locations. You may find that you actually don't
+your merge requests, pipeline details pages, and other locations. You may find that you actually don't
 need to configure anything to have these appear.
 
 If they aren't working as expected, or if you'd like to see what's available, our [CI feature index](../index.md#gitlab-cicd-features) has the full list

doc/ci/pipelines/index.md

@@ -50,14 +50,14 @@ Pipelines can be configured in many different ways:
   followed by the next stage.
 - [Directed Acyclic Graph Pipeline (DAG) pipelines](../directed_acyclic_graph/index.md) are based on relationships
   between jobs and can run more quickly than basic pipelines.
-- [Pipelines for Merge Requests](../pipelines/merge_request_pipelines.md) run for merge
+- [Pipelines for merge requests](../pipelines/merge_request_pipelines.md) run for merge
   requests only (rather than for every commit).
-- [Pipelines for Merged Results](../pipelines/pipelines_for_merged_results.md)
+- [Pipelines for merged results](../pipelines/pipelines_for_merged_results.md)
   are merge request pipelines that act as though the changes from the source branch have
   already been merged into the target branch.
-- [Merge Trains](../pipelines/merge_trains.md)
+- [Merge trains](../pipelines/merge_trains.md)
   use pipelines for merged results to queue merges one after the other.
-- [Parent-Child pipelines](parent_child_pipelines.md) break down complex pipelines
+- [Parent-child pipelines](parent_child_pipelines.md) break down complex pipelines
   into one parent pipeline that can trigger multiple child sub-pipelines, which all
   run in the same project and with the same SHA. This pipeline architecture is commonly used for mono-repos.
 - [Multi-project pipelines](multi_project_pipelines.md) combine pipelines for different projects together.

doc/ci/pipelines/parent_child_pipelines.md

@@ -100,7 +100,7 @@ microservice_a:
 
 ## Merge request child pipelines
 
-To trigger a child pipeline as a [Merge Request Pipeline](merge_request_pipelines.md) we need to:
+To trigger a child pipeline as a [merge request pipeline](merge_request_pipelines.md) we need to:
 
 - Set the trigger job to run on merge requests:
 

doc/ci/troubleshooting.md

@@ -69,11 +69,11 @@ if you are using that type:
   and run separate pipelines in the same project. You can also
   [dynamically generate the child pipeline's configuration](pipelines/parent_child_pipelines.md#dynamic-child-pipelines)
   at runtime.
-- [Pipelines for Merge Requests](pipelines/merge_request_pipelines.md): Run a pipeline
+- [Pipelines for merge requests](pipelines/merge_request_pipelines.md): Run a pipeline
   in the context of a merge request.
-  - [Pipelines for Merge Results](pipelines/pipelines_for_merged_results.md):
+  - [Pipelines for merge results](pipelines/pipelines_for_merged_results.md):
     Pipelines for merge requests that run on the combined source and target branch
-  - [Merge Trains](pipelines/merge_trains.md):
+  - [Merge trains](pipelines/merge_trains.md):
     Multiple pipelines for merged results that queue and run automatically before
     changes are merged.
 

doc/ci/unit_test_reports.md

@@ -21,7 +21,7 @@ report on the merge request so that it's easier and faster to identify the
 failure without having to check the entire log. Unit test reports currently
 only support test reports in the JUnit report format.
 
-If you don't use Merge Requests but still want to see the unit test report
+If you don't use merge requests but still want to see the unit test report
 output without searching through job logs, the full
 [Unit test reports](#viewing-unit-test-reports-on-gitlab) are available
 in the pipeline detail view.
@@ -67,7 +67,7 @@ execution time and the error output.
 
 ### Number of recent failures
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241759) in Merge Requests in GitLab 13.7.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241759) in merge requests in GitLab 13.7.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/268249) in GitLab 13.8.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235525) in Test Reports in GitLab 13.9.
 

doc/development/cached_queries.md

@@ -163,5 +163,5 @@ factors help improve the overall execution time:
 ## For more information
 
 - [Metrics that would help us detect the potential N+1 Cached SQL calls](https://gitlab.com/gitlab-org/gitlab/-/issues/259007)
-- [Merge Request performance guidelines for cached queries](merge_request_performance_guidelines.md#cached-queries)
+- [Merge request performance guidelines for cached queries](merge_request_performance_guidelines.md#cached-queries)
 - [Improvements for biggest offenders](https://gitlab.com/groups/gitlab-org/-/epics/4508)

doc/development/code_review.md

@@ -285,7 +285,7 @@ Maintainers should check before merging if the merge request is approved by the
 required approvers. If still awaiting further approvals from others, remove yourself as a reviewer then `@` mention the author and explain why in a comment. Stay as reviewer if you're merging the code.
 
 Maintainers must check before merging if the merge request is introducing new
-vulnerabilities, by inspecting the list in the Merge Request
+vulnerabilities, by inspecting the list in the merge request
 [Security Widget](../user/application_security/index.md).
 When in doubt, a [Security Engineer](https://about.gitlab.com/company/team/) can be involved. The list of detected
 vulnerabilities must be either empty or containing:
@@ -296,8 +296,8 @@ vulnerabilities must be either empty or containing:
 Maintainers should **never** dismiss vulnerabilities to "empty" the list,
 without duly verifying them.
 
-Note that certain Merge Requests may target a stable branch. These are rare
-events. These types of Merge Requests cannot be merged by the Maintainer.
+Note that certain merge requests may target a stable branch. These are rare
+events. These types of merge requests cannot be merged by the Maintainer.
 Instead, these should be sent to the [Release Manager](https://about.gitlab.com/community/release-managers/).
 
 After merging, a maintainer should stay as the reviewer listed on the merge request.

doc/development/database_review.md

@@ -66,7 +66,7 @@ Refer to [Preparation when adding or modifying queries](#preparation-when-adding
 
 ### Roles and process
 
-A Merge Request **author**'s role is to:
+A merge request **author**'s role is to:
 
 - Decide whether a database review is needed.
 - If database review is needed, add the ~database label.

doc/development/dependencies.md

@@ -51,6 +51,6 @@ This has certain benefits as outlined in our <a href="https://docs.gitlab.com/ee
 
 You might find that we do not currently update DEPENDENCY automatically, but we are planning to do so in [the near future](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21).
 
-Thank you for understanding, I will close this Merge Request.
+Thank you for understanding, I will close this merge request.
 /close
 ```

doc/development/diffs.md

@@ -35,7 +35,7 @@ have changed since then, it should still serve as a good introduction.
 
 ### Merge request diffs
 
-When refreshing a Merge Request (pushing to a source branch, force-pushing to target branch, or if the target branch now contains any commits from the MR)
+When refreshing a merge request (pushing to a source branch, force-pushing to target branch, or if the target branch now contains any commits from the MR)
 we fetch the comparison information using `Gitlab::Git::Compare`, which fetches `base` and `head` data using Gitaly and diff between them through
 `Gitlab::Git::Diff.between`.
 The diffs fetching process _limits_ single file diff sizes and the overall size of the whole diff through a series of constant values. Raw diff files are
@@ -45,7 +45,7 @@ Even though diffs larger than 10% of the value of `ApplicationSettings#diff_max_
 we still keep them on PostgreSQL. However, diff files larger than defined _safety limits_
 (see the [Diff limits section](#diff-limits)) are _not_ persisted in the database.
 
-In order to present diffs information on the Merge Request diffs page, we:
+In order to present diffs information on the merge request diffs page, we:
 
 1. Fetch all diff files from database `merge_request_diff_files`
 1. Fetch the _old_ and _new_ file blobs in batch to:

doc/development/export_csv.md

@@ -12,7 +12,7 @@ This document lists the different implementations of CSV export in GitLab codeba
 |---|---|---|---|---|
 | Streaming | - Query and yield data in batches to a response stream.<br>- Download starts immediately. | - Report available immediately. | - No progress indicator.<br>- Requires a reliable connection. | [Export Audit Event Log](../administration/audit_events.md#export-to-csv) |
 | Downloading | - Query and write data in batches to a temporary file.<br>- Loads the file into memory.<br>- Sends the file to the client. | - Report available immediately. | - Large amount of data might cause request timeout.<br>- Memory intensive.<br>- Request expires when user navigates to a different page. | [Export Chain of Custody Report](../user/compliance/compliance_report/#chain-of-custody-report) |
-| As email attachment | - Asynchronously process the query with background job.<br>- Email uses the export as an attachment. | - Asynchronous processing. | - Requires users use a different app (email) to download the CSV.<br>- Email providers may limit attachment size. | - [Export Issues](../user/project/issues/csv_export.md)<br>- [Export Merge Requests](../user/project/merge_requests/csv_export.md) |
+| As email attachment | - Asynchronously process the query with background job.<br>- Email uses the export as an attachment. | - Asynchronous processing. | - Requires users use a different app (email) to download the CSV.<br>- Email providers may limit attachment size. | - [Export issues](../user/project/issues/csv_export.md)<br>- [Export merge requests](../user/project/merge_requests/csv_export.md) |
 | As downloadable link in email (*) | - Asynchronously process the query with background job.<br>- Email uses an export link. | - Asynchronous processing.<br>- Bypasses email provider attachment size limit. | - Requires users use a different app (email).<br>- Requires additional storage and cleanup. | [Export User Permissions](https://gitlab.com/gitlab-org/gitlab/-/issues/1772) |
 | Polling (non-persistent state) | - Asynchronously processes the query with the background job.<br>- Frontend(FE) polls every few seconds to check if CSV file is ready. | - Asynchronous processing.<br>- Automatically downloads to local machine on completion.<br>- In-app solution. | - Non-persistable request - request expires when user navigates to a different page.<br>- API is processed for each polling request. | [Export Vulnerabilities](../user/application_security/vulnerability_report/#export-vulnerability-details) |
 | Polling (persistent state) (*) | - Asynchronously processes the query with background job.<br>- Backend (BE) maintains the export state<br>- FE polls every few seconds to check status.<br>- FE shows 'Download link' when export is ready.<br>- User can download or regenerate a new report. | - Asynchronous processing.<br>- No database calls made during the polling requests (HTTP 304 status is returned until export status changes).<br>- Does not require user to stay on page until export is complete.<br>- In-app solution.<br>- Can be expanded into a generic CSV feature (such as dashboard / CSV API). | - Requires to maintain export states in DB.<br>- Does not automatically download the CSV export to local machine, requires users to click 'Download' button. | [Export Merge Commits Report](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43055) |

doc/development/feature_flags/index.md

@@ -169,7 +169,7 @@ Each feature flag is defined in a separate YAML file consisting of a number of f
 | `name`              | yes      | Name of the feature flag.                                      |
 | `type`              | yes      | Type of feature flag.                                          |
 | `default_enabled`   | yes      | The default state of the feature flag that is strictly validated, with `default_enabled:` passed as an argument. |
-| `introduced_by_url` | no       | The URL to the Merge Request that introduced the feature flag. |
+| `introduced_by_url` | no       | The URL to the merge request that introduced the feature flag. |
 | `rollout_issue_url` | no       | The URL to the Issue covering the feature flag rollout.        |
 | `milestone`         | no       | Milestone in which the feature was added.                      |
 | `group`             | no       | The [group](https://about.gitlab.com/handbook/product/categories/#devops-stages) that owns the feature flag. |

doc/development/features_inside_dot_gitlab.md

@@ -11,7 +11,7 @@ When implementing new features, please refer to these existing features to avoid
 
 - [Custom Dashboards](../operations/metrics/dashboards/index.md#add-a-new-dashboard-to-your-project): `.gitlab/dashboards/`.
 - [Issue Templates](../user/project/description_templates.md#create-an-issue-template): `.gitlab/issue_templates/`.
-- [Merge Request Templates](../user/project/description_templates.md#create-a-merge-request-template): `.gitlab/merge_request_templates/`.
+- [Merge request Templates](../user/project/description_templates.md#create-a-merge-request-template): `.gitlab/merge_request_templates/`.
 - [GitLab Agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/configuration_repository.md#layout): `.gitlab/agents/`.
 - [CODEOWNERS](../user/project/code_owners.md#set-up-code-owners): `.gitlab/CODEOWNERS`.
 - [Route Maps](../ci/review_apps/#route-maps): `.gitlab/route-map.yml`.

doc/development/index.md

@@ -224,7 +224,7 @@ the [reviewer values](https://about.gitlab.com/handbook/engineering/workflow/rev
 - [Sidekiq guidelines](sidekiq/index.md) for working with Sidekiq workers
 - [Working with Gitaly](gitaly.md)
 - [Elasticsearch integration docs](elasticsearch.md)
-- [Working with Merge Request diffs](diffs.md)
+- [Working with merge request diffs](diffs.md)
 - [Approval Rules](approval_rules.md)
 - [Repository mirroring](repository_mirroring.md)
 - [File uploads](uploads.md)

doc/development/integrations/secure.md

@@ -10,7 +10,7 @@ Integrating a security scanner into GitLab consists of providing end users
 with a [CI job definition](../../ci/yaml/index.md)
 they can add to their CI configuration files to scan their GitLab projects.
 This CI job should then output its results in a GitLab-specified format. These results are then
-automatically presented in various places in GitLab, such as the Pipeline view, Merge Request
+automatically presented in various places in GitLab, such as the Pipeline view, merge request
 widget, and Security Dashboard.
 
 The scanning job is usually based on a [Docker image](https://docs.docker.com/)

doc/development/issuable-like-models.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 GitLab Rails codebase contains several models that hold common functionality and behave similarly to
 [Issues](../user/project/issues/index.md). Other examples of "issuables"
-are [Merge Requests](../user/project/merge_requests/index.md) and
+are [merge requests](../user/project/merge_requests/index.md) and
 [Epics](../user/group/epics/index.md).
 
 This guide accumulates guidelines on working with such Rails models.

doc/development/issue_types.md

@@ -11,7 +11,7 @@ We are deprecating Issue Types as of GitLab 14.2 in favor of [Work Items and Wor
 
 Sometimes when a new resource type is added it's not clear if it should be only an
 "extension" of Issue (Issue Type) or if it should be a new first-class resource type
-(similar to Issue, Epic, Merge Request, Snippet).
+(similar to issue, epic, merge request, snippet).
 
 The idea of Issue Types was first proposed in [this
 issue](https://gitlab.com/gitlab-org/gitlab/-/issues/8767) and its usage was

doc/development/service_ping/metrics_dictionary.md

@@ -49,7 +49,7 @@ Each metric is defined in a separate YAML file consisting of a number of fields:
 | `tier`              | yes      | `array`; may contain one or a combination of `free`, `premium` or `ultimate`. The [tier]( https://about.gitlab.com/handbook/marketing/strategic-marketing/tiers/) where the tracked feature is available. This should be verbose and contain all tiers where a metric is available. |
 | `milestone`         | no       | The milestone when the metric is introduced. |
 | `milestone_removed` | no       | The milestone when the metric is removed. |
-| `introduced_by_url` | no       | The URL to the Merge Request that introduced the metric. |
+| `introduced_by_url` | no       | The URL to the merge request that introduced the metric. |
 | `repair_issue_url`  | no       | The URL of the issue that was created to repair a metric with a `broken` status. |
 | `options`           | no       | `object`: options information needed to calculate the metric value. |
 | `skip_validation`   | no       | This should **not** be set. [Used for imported metrics until we review, update and make them valid](https://gitlab.com/groups/gitlab-org/-/epics/5425). |

doc/integration/elasticsearch.md

@@ -517,7 +517,7 @@ When performing a search, the GitLab index uses the following scopes:
 | `projects`       | Project data (default) |
 | `blobs`          | Code                   |
 | `issues`         | Issue data             |
-| `merge_requests` | Merge Request data     |
+| `merge_requests` | Merge request data     |
 | `milestones`     | Milestone data         |
 | `notes`          | Note data              |
 | `snippets`       | Snippet data           |

doc/integration/jenkins_deprecated.md

@@ -19,7 +19,7 @@ This service was [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/1600) i
 Integration includes:
 
 - Trigger Jenkins build after push to repository
-- Show build status on Merge Request page
+- Show build status on Merge request page
 
 Requirements:
 

doc/topics/git/merge_conflicts.md

@@ -23,7 +23,7 @@ comments: false
 1. Fix conflicts on the `conflicts.rb` file.
 1. Stage the file and continue rebasing.
 1. Force push the changes.
-1. Finally continue with the Merge Request.
+1. Finally continue with the merge request.
 
 ```shell
 git checkout -b conflicts_branch

doc/user/admin_area/analytics/usage_trends.md

@@ -33,7 +33,7 @@ At the top of the page, Usage Trends shows total counts for:
 - Projects
 - Groups
 - Issues
-- Merge Requests
+- Merge requests
 - Pipelines
 
 These figures can be useful for understanding how much data your instance contains in total.

doc/user/application_security/secret_detection/index.md

@@ -63,7 +63,7 @@ as shown in the following table:
 | [Configure Secret Detection Scanners](#configuration)           | **{check-circle}**  | **{check-circle}** |
 | [Customize Secret Detection Settings](#customizing-settings)    | **{check-circle}**  | **{check-circle}** |
 | View [JSON Report](../sast/index.md#reports-json-format)        | **{check-circle}**  | **{check-circle}** |
-| Presentation of JSON Report in Merge Request                    | **{dotted-circle}** | **{check-circle}** |
+| Presentation of JSON Report in merge request                    | **{dotted-circle}** | **{check-circle}** |
 | View identified secrets in the pipelines' **Security** tab      | **{dotted-circle}** | **{check-circle}** |
 | [Interaction with Vulnerabilities](../vulnerabilities/index.md) | **{dotted-circle}** | **{check-circle}** |
 | [Access to Security Dashboard](../security_dashboard/index.md)  | **{dotted-circle}** | **{check-circle}** |
@@ -370,7 +370,7 @@ For information on this, see the [general Application Security troubleshooting s
 
 ### Error: `Couldn't run the gitleaks command: exit status 2`
 
-If a pipeline is triggered from a Merge Request containing 60 commits while the `GIT_DEPTH` variable's
+If a pipeline is triggered from a merge request containing 60 commits while the `GIT_DEPTH` variable's
 value is less than that, the Secret Detection job fails as the clone is not deep enough to contain all of the
 relevant commits. For information on the current default value, see the
 [pipeline configuration documentation](../../../ci/pipelines/settings.md#limit-the-number-of-changes-fetched-during-clone).

doc/user/index.md

@@ -44,7 +44,7 @@ GitLab is a Git-based platform that integrates a great number of essential tools
 - Tracking proposals for new implementations, bug reports, and feedback with a
   fully featured [Issue tracker](project/issues/index.md).
 - Organizing and prioritizing with [issue boards](project/issue_board.md).
-- Reviewing code in [Merge Requests](project/merge_requests/index.md) with live-preview changes per
+- Reviewing code in [merge requests](project/merge_requests/index.md) with live-preview changes per
   branch with [Review Apps](../ci/review_apps/index.md).
 - Building, testing, and deploying with built-in [Continuous Integration](../ci/index.md).
 - Deploying personal and professional static websites with [GitLab Pages](project/pages/index.md).
@@ -56,7 +56,7 @@ GitLab is a Git-based platform that integrates a great number of essential tools
 With GitLab Enterprise Edition, you can also:
 
 - Improve collaboration with:
-  - [Merge Request Approvals](project/merge_requests/approvals/index.md).
+  - [Merge request approvals](project/merge_requests/approvals/index.md).
   - [Multiple Assignees for Issues](project/issues/multiple_assignees_for_issues.md).
   - [Multiple issue boards](project/issue_board.md#multiple-issue-boards).
 - Create formal relationships between issues with [linked issues](project/issues/related_issues.md).
@@ -152,8 +152,8 @@ it all at once, from one single project.
 - [Repositories](project/repository/index.md): Host your codebase in
   repositories with version control and as part of a fully integrated platform.
 - [Issues](project/issues/index.md): Explore the best of GitLab Issues' features.
-- [Merge Requests](project/merge_requests/index.md): Collaborate on code,
-  reviews, live preview changes per branch, and request approvals with Merge Requests.
+- [Merge requests](project/merge_requests/index.md): Collaborate on code,
+  reviews, live preview changes per branch, and request approvals with merge requests.
 - [Milestones](project/milestones/index.md): Work on multiple issues and merge
   requests towards the same target date with Milestones.
 

doc/user/infrastructure/iac/index.md

@@ -83,12 +83,12 @@ GitLab can be used as a [Terraform module registry](../../packages/terraform_mod
 to create and publish Terraform modules to a private registry specific to your
 top-level namespace.
 
-## Terraform integration in Merge Requests
+## Terraform integration in merge requests
 
 Collaborating around Infrastructure as Code (IaC) changes requires both code changes
 and expected infrastructure changes to be checked and approved. GitLab provides a
 solution to help collaboration around Terraform code changes and their expected
-effects using the Merge Request pages. This way users don't have to build custom
+effects using the merge request pages. This way users don't have to build custom
 tools or rely on 3rd party solutions to streamline their IaC workflows.
 
 Read more on setting up and [using the merge request integrations](mr_integration.md).

doc/user/infrastructure/iac/mr_integration.md

@@ -4,9 +4,9 @@ group: Configure
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Terraform integration in Merge Requests **(FREE)**
+# Terraform integration in merge requests **(FREE)**
 
-Collaborating around Infrastructure as Code (IaC) changes requires both code changes and expected infrastructure changes to be checked and approved. GitLab provides a solution to help collaboration around Terraform code changes and their expected effects using the Merge Request pages. This way users don't have to build custom tools or rely on 3rd party solutions to streamline their IaC workflows.
+Collaborating around Infrastructure as Code (IaC) changes requires both code changes and expected infrastructure changes to be checked and approved. GitLab provides a solution to help collaboration around Terraform code changes and their expected effects using the merge request pages. This way users don't have to build custom tools or rely on 3rd party solutions to streamline their IaC workflows.
 
 ## Output Terraform Plan information into a merge request
 
@@ -83,7 +83,7 @@ To manually configure a GitLab Terraform Report artifact:
 
 1. Running the pipeline displays the widget in the merge request, like this:
 
-   ![Merge Request Terraform widget](img/terraform_plan_widget_v13_2.png)
+   ![merge request Terraform widget](img/terraform_plan_widget_v13_2.png)
 
 1. Clicking the **View Full Log** button in the widget takes you directly to the
    plan output present in the pipeline logs:
@@ -151,8 +151,8 @@ apply:
 
 ### Multiple Terraform Plan reports
 
-Starting with GitLab version 13.2, you can display multiple reports on the Merge Request
-page. The reports also display the `artifacts: name:`. See example below for a suggested setup.
+Starting with GitLab version 13.2, you can display multiple reports on a merge request.
+The reports also display the `artifacts: name:`. See example below for a suggested setup.
 
 ```yaml
 default:

doc/user/project/settings/index.md

@@ -249,7 +249,7 @@ Use the switches to enable or disable the following features:
 |:---------------------------------|:--------------------------|:--------------|
 | **Issues**                       | ✓                         | Activates the GitLab issues tracker. |
 | **Repository**                   | ✓                         | Enables [repository](../repository/) functionality |
-| **Merge Requests**               | ✓                         | Enables [merge request](../merge_requests/) functionality; also see [Merge request settings](#merge-request-settings). |
+| **Merge requests**               | ✓                         | Enables [merge request](../merge_requests/) functionality; also see [Merge request settings](#merge-request-settings). |
 | **Forks**                        | ✓                         | Enables [forking](../repository/forking_workflow.md) functionality. |
 | **Git Large File Storage (LFS)** |                           | Enables the use of [large files](../../../topics/git/lfs/index.md#git-large-file-storage-lfs). |
 | **Packages**                     |                           | Supports configuration of a [package registry](../../../administration/packages/index.md#gitlab-package-registry-administration) functionality. |
@@ -281,7 +281,7 @@ Some features depend on others:
 
 - If you disable **Repository** functionality, GitLab also disables the following
   features for your project:
-  - **Merge Requests**
+  - **Merge requests**
   - **CI/CD**
   - **Container Registry**
   - **Git Large File Storage**

doc/user/search/index.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## Search issues and merge requests
 
-To search through issues and merge requests in multiple projects, on the top bar, select the **Issues** or **Merge Requests** links.
+To search through issues and merge requests in multiple projects, on the top bar, select the **Issues** or **Merge requests** links.
 
 The numbers indicate how many issues, merge requests, and to-do items are assigned to you:
 
@@ -36,7 +36,7 @@ in the search field in the upper right corner:
 > - Filter by child Epics was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9029) in GitLab Ultimate 13.0.
 > - Filter by Iterations was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118742) in GitLab 13.6. Moved to GitLab Premium in 13.9.
 
-Follow these steps to filter the **Issues** and **Merge Requests** list pages in projects and
+Follow these steps to filter the **Issues** and **Merge requests** list pages in projects and
 groups:
 
 1. Click in the field **Search or filter results...**.
@@ -95,7 +95,7 @@ You can add this URL to your feed reader.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/39908) in GitLab 12.1.
 
-You can filter the **Issues** list to individual instances by their ID. For example, enter filter `#10` to return only issue 10. The same applies to the **Merge Requests** list. Enter filter `#30` to return only merge request 30.
+You can filter the **Issues** list to individual instances by their ID. For example, enter filter `#10` to return only issue 10. The same applies to the **Merge requests** list. Enter filter `#30` to return only merge request 30.
 
 ![filter issues by specific ID](img/issue_search_by_id.png)