Update capitalization of "merge request"

Fixing lots of random instances of "merge request" where it was
miscapitalized. The "M" should only be capitalized at the beginning
of a sentence or slug, and the "R" should never be capitalized.

bin/changelog

@@ -71,7 +71,7 @@ class ChangelogOptionParser
           options.force = value
         end
 
-        opts.on('-m', '--merge-request [integer]', Integer, 'Merge Request ID') do |value|
+        opts.on('-m', '--merge-request [integer]', Integer, 'Merge request ID') do |value|
           options.merge_request = value
         end
 

bin/feature-flag

@@ -61,7 +61,7 @@ class FeatureFlagOptionParser
           options.force = value
         end
 
-        opts.on('-m', '--introduced-by-url [string]', String, 'URL of Merge Request introducing the Feature Flag') do |value|
+        opts.on('-m', '--introduced-by-url [string]', String, 'URL of merge request introducing the Feature Flag') do |value|
           options.introduced_by_url = value
         end
 

data/whats_new/202008180003_13_01.yml

@@ -12,7 +12,7 @@
   image_url: https://about.gitlab.com/images/13_1/alert_management.png
   published_at: 2020-06-22
   release: 13.1
-- title: Accessibility Testing Merge Request Widget
+- title: Accessibility testing merge request widget
   body: |
     Today, developers who want to ensure their application is accessible to everyone suffer from slow feedback loops, which make it difficult to catch degradations in their code.
 
@@ -36,9 +36,9 @@
   image_url: https://about.gitlab.com/images/13_1/resolve-design-comment.gif
   published_at: 2020-06-22
   release: 13.1
-- title: Merge Request Reviews moved to Free
+- title: Merge request reviews moved to Free
   body: |
-    Originally introduced in GitLab 11.4 as a GitLab Premium feature, Merge Request Reviews allow merge request reviewers to submit multiple comments at once, cutting down on notification noise for the merge request author, and allowing for a more cohesive and streamlined review process.
+    Originally introduced in GitLab 11.4 as a GitLab Premium feature, merge request reviews allow merge request reviewers to submit multiple comments at once, cutting down on notification noise for the merge request author, and allowing for a more cohesive and streamlined review process.
   stage: Create
   self-managed: true
   gitlab-com: true

data/whats_new/202009150001_13_03.yml

@@ -27,7 +27,7 @@
   body: |
     Dynamic Application Security Testing at GitLab has always been focused on integrating DAST into the DevOps pipeline and enabling developers to scan their review app, running website, or API for vulnerabilities as early as possible.
 
-    However, there are times when it is necessary to run a DAST scan against an already deployed application when no code changes have been made and no Merge Request has been created. These scans could be needed for audit or compliance reasons, to debug and reproduce an issue that has been found, or to support teams who do not commit code, such as security analysts.
+    However, there are times when it is necessary to run a DAST scan against an already deployed application when no code changes have been made and no merge request has been created. These scans could be needed for audit or compliance reasons, to debug and reproduce an issue that has been found, or to support teams who do not commit code, such as security analysts.
 
     Because of the need for DAST scans that are not triggered by a code change or MR, on-demand DAST testing is now available. You don’t need configuration files or code to start running on-demand scans. Configuration options for on-demand DAST scans are available within the GitLab UI.
   stage: Secure

data/whats_new/202011230001_13_06.yml

@@ -16,9 +16,9 @@
   release: 13.6
 - title: Display Code Quality severity ratings
   body: |
-    The Code Quality feature in GitLab is great at showing what quality violations exist in a project or are changing in the Merge Request. However, understanding which of those violations is the most important is not clear in the GitLab interface today.
+    The Code Quality feature in GitLab is great at showing what quality violations exist in a project or are changing in the merge request. However, understanding which of those violations is the most important is not clear in the GitLab interface today.
 
-    With the Full Code Quality Report and Merge Request Widget, now you can see the severity rating. This makes it easy for you to understand which code quality violations are most important to resolve before merging and reduces the technical debt in your project.
+    With the Full Code Quality Report and merge request widget, now you can see the severity rating. This makes it easy for you to understand which code quality violations are most important to resolve before merging and reduces the technical debt in your project.
   stage: Verify
   self-managed: true
   gitlab-com: true

data/whats_new/202012160001_13_07.yml

@@ -10,7 +10,7 @@
   image_url: https://img.youtube.com/vi/G8fYYrxqF5E/hqdefault.jpg
   published_at: 2020-12-22
   release: 13.7
-- title: Reviewers for Merge Requests
+- title: Reviewers for merge requests
   body: |
     Asking a colleague to review your code should be a routine part of contributing code, but it's often needlessly complex. A simple task like asking for a review can lead to confusion. For example, how should you ask? An email? Comment? Chat message? Without a formal process, reviews can be inconsistent and hard to keep track of. Previously, an option was to assign a reviewer to a merge request, but even with this formality, both the author and the reviewer appeared in the same assignee field, making it hard for other team members to know who was doing what.
 

data/whats_new/202103220001_13_10.yml

@@ -74,13 +74,13 @@
   image_url:  https://about.gitlab.com/images/13_10/integrate_alerts.png
   published_at: 2021-03-22
   release: 13.10
-- title: "Merge Request test summary usability improvements"
+- title: "Merge request test summary usability improvements"
   body: |
-    Increasing the number of tests or custom metrics in a pipeline gives you additional confidence and information. However, increasing these to a large number has also come with a degraded visual experience of the Merge Request page. The Merge Request test summary widget has been improved so you can better differentiate between the different test jobs in the widget, making it easier to identify which job contains failed tests.
+    Increasing the number of tests or custom metrics in a pipeline gives you additional confidence and information. However, increasing these to a large number has also come with a degraded visual experience of the merge request page. The merge request test summary widget has been improved so you can better differentiate between the different test jobs in the widget, making it easier to identify which job contains failed tests.
 
     It has also been challenging to understand why a `junit.xml` file was not parsed without errors being presented. Now you can see parsing errors in the Test Summary widget, as well as the Unit Test report, to identify and resolve structural issues and see test results in GitLab.
 
-    The [Metrics Reports](https://docs.gitlab.com/ee/ci/metrics_reports.html) widget [(Premium and Ultimate)](https://about.gitlab.com/pricing/) is now sorted so new, changed, and unchanged metrics are all together, making the experience of finding metrics that have changed as part of the Merge Request more intuitive.
+    The [Metrics Reports](https://docs.gitlab.com/ee/ci/metrics_reports.html) widget [(Premium and Ultimate)](https://about.gitlab.com/pricing/) is now sorted so new, changed, and unchanged metrics are all together, making the experience of finding metrics that have changed as part of the merge request more intuitive.
   stage: Verify
   self-managed: true
   gitlab-com: true

data/whats_new/templates/YYYYMMDD0001_XX_YY.yml

@@ -7,7 +7,7 @@
 # For more information please refer to the handbook documentation here:
 # https://about.gitlab.com/handbook/marketing/blog/release-posts/index.html#create-mr-for-whats-new-entries
 #
-# Please delete this line and above before submitting your Merge Request.
+# Please delete this line and above before submitting your merge request.
 
 - title: # Match the release post entry
   body: | # Do not modify this line, instead modify the lines below.

doc/development/usage_ping/dictionary.md

@@ -14616,7 +14616,7 @@ Tiers: `free`
 
 ### `usage_activity_by_stage.create.merge_requests_with_added_rules`
 
-Merge Requests with added rules
+Merge requests with added rules
 
 [YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210216175047_merge_requests_with_added_rules.yml)
 
@@ -16560,7 +16560,7 @@ Tiers: `free`
 
 ### `usage_activity_by_stage_monthly.create.merge_requests_with_added_rules`
 
-Merge Requests with added rules
+Merge requests with added rules
 
 [YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210216175103_merge_requests_with_added_rules.yml)
 

ee/config/metrics/counts_28d/20210216175103_merge_requests_with_added_rules.yml

 ---
 key_path: usage_activity_by_stage_monthly.create.merge_requests_with_added_rules
-description: Merge Requests with added rules
+description: Merge requests with added rules
 product_section: dev
 product_stage: create
 product_group: group::code review

ee/config/metrics/counts_all/20210216175047_merge_requests_with_added_rules.yml

 ---
 key_path: usage_activity_by_stage.create.merge_requests_with_added_rules
-description: Merge Requests with added rules
+description: Merge requests with added rules
 product_section: dev
 product_stage: create
 product_group: group::code review

ee/fixtures/insights/default.yml

@@ -38,15 +38,15 @@ issues:
           - S::4
         group_by: month
 mergeRequests:
-  title: Merge Requests Dashboard
+  title: Merge requests dashboard
   charts:
-    - title: Merge Requests merged per week
+    - title: Merge requests merged per week
       type: bar
       query:
         issuable_type: merge_request
         issuable_state: merged
         group_by: week
-    - title: Merge Requests merged per month
+    - title: Merge requests merged per month
       type: bar
       query:
         issuable_type: merge_request

ee/lib/ee/api/helpers/projects_helpers.rb

@@ -34,7 +34,7 @@ module EE
             optional :import_url, type: String, desc: 'URL from which the project is imported'
             optional :fallback_approvals_required, type: Integer, desc: 'Overall approvals required when no rule is present'
             optional :issues_template, type: String, desc: 'Default description for Issues. Description is parsed with GitLab Flavored Markdown.'
-            optional :merge_requests_template, type: String, desc: 'Default description for Merge Requests. Description is parsed with GitLab Flavored Markdown.'
+            optional :merge_requests_template, type: String, desc: 'Default description for merge requests. Description is parsed with GitLab Flavored Markdown.'
           end
         end
 

scripts/verify-tff-mapping

@@ -8,7 +8,7 @@ require 'set'
 # The verification depend on the presence of actual test files,
 # so they would fail if one of the test files mentioned here is deleted.
 # To minimize the chance of this test failing due to unrelated changes,
-# the test files are chosen to be critical files that are unlikely to be deleted in a typical Merge Request
+# the test files are chosen to be critical files that are unlikely to be deleted in a typical merge request
 tests = [
   {
     explanation: 'EE code should map to respective spec',

workhorse/_support/changelog

@@ -52,7 +52,7 @@ class ChangelogOptionParser
           options.force = value
         end
 
-        opts.on('-m', '--merge-request [integer]', Integer, 'Merge Request ID') do |value|
+        opts.on('-m', '--merge-request [integer]', Integer, 'Merge request ID') do |value|
           options.merge_request = value
         end