Apply 1 suggestion(s) to 1 file(s)

Co-authored-by: Suzanne Selhorn <sselhorn@gitlab.com>

data/whats_new/202008180001_12_10.yml

@@ -44,7 +44,7 @@
   description: |
     Until now, the only way to get Jira issues into GitLab was manually, with our CSV importer, or by hand-rolling your own migration utility.
 
-    GitLab 12.10 includes an [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) to automatically import your Jira issues into GitLab. This is the first of [many planned enhancements](https://gitlab.com/groups/gitlab-org/-/epics/2738) to make transitioning from Jira to GitLab as frictionless as possible.
+    GitLab 12.10 includes an [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-valuable-change-mvc) to automatically import your Jira issues into GitLab. This is the first of [many planned enhancements](https://gitlab.com/groups/gitlab-org/-/epics/2738) to make transitioning from Jira to GitLab as frictionless as possible.
   stage: Plan
   self-managed: true
   gitlab-com: true

data/whats_new/202205220001_15_0.yml

@@ -58,7 +58,7 @@
   release: 15.0  # XX.Y
 - name: Link external organizations and contacts to issues  # Match the release post entry
   description: |   # Do not modify this line, instead modify the lines below.
-    GitLab 15.0 introduces the first [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) toward [managing and billing external customers from GitLab](https://gitlab.com/groups/gitlab-org/-/epics/5323). With the customer relations management (CRM) feature, you can:
+    GitLab 15.0 introduces the first [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-valuable-change-mvc) toward [managing and billing external customers from GitLab](https://gitlab.com/groups/gitlab-org/-/epics/5323). With the customer relations management (CRM) feature, you can:
 
     - Create organizations and contacts.
     - Set a default bill rate for an organization.

doc/development/contributing/merge_request_workflow.md

@@ -78,7 +78,7 @@ For a walkthrough of the contribution process, see [Tutorial: Make a GitLab cont
 
 *Live by smaller iterations.* Keep the amount of changes in a single MR **as small as possible**.
 If you want to contribute a large feature, think very carefully about what the
-[minimum viable change](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc)
+[minimum valuable change](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-valuable-change-mvc)
 is. Can you split the functionality into two smaller MRs? Can you submit only the
 backend/API code? Can you start with a very simple UI? Can you do just a part of the
 refactor?

doc/policy/experiment-beta-support.md

@@ -11,7 +11,7 @@ GitLab sometimes releases features as experimental or beta, and users can opt in
 Some reasons for these kinds of feature releases include:
 
 - Validating the edge-cases of scale, support, and maintenance burden of features in their current form for every designed use case.
-- Features not complete enough to be considered an [MVC](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc),
+- Features not complete enough to be considered an [MVC](https://handbook.gitlab.com/handbook/product/product-principles/#the-minimal-valuable-change-mvc),
   but added to the codebase as part of the development process.
 
 Please note that some features may not be aligned to these recommendations if they were developed before the recommendations were in place,