Reword option descriptions

doc/administration/whats-new.md

@@ -37,8 +37,8 @@ or you can hide it. To configure it:
 
    | Option | Description |
    | ------ | ----------- |
-   | Enable What's new: All tiers | What's new presents new features from all tiers to help you keep track of all new features. |
-   | Enable What's new: Current tier only | What's new presents new features for your current subscription tier, while hiding new features not available to your subscription tier. |
-   | Disable What's new | What's new is disabled and can no longer be viewed. |
+   | Enable What's new: All tiers | Presents new features from all tiers. |
+   | Enable What's new: Current tier only | Presents new features for your current subscription tier, and hides new features outside of your tier. |
+   | Disable What's new | Disables this feature, so it's no longer displayed under the **{question}** icon. |
 
 1. Select **Save changes**.

doc/development/contributing/merge_request_workflow.md

@@ -94,18 +94,20 @@ document from the Kubernetes team also has some great points regarding this.
 
 Commit messages should follow the guidelines below, for reasons explained by Chris Beams in [How to Write a Git Commit Message](https://cbea.ms/git-commit/):
 
-- The commit subject and body must be separated by a blank line.
-- The commit subject must start with a capital letter.
-- The commit subject must not be longer than 72 characters.
-- The commit subject must not end with a period.
-- The commit body must not contain more than 72 characters per line.
-- The commit subject or body must not contain Emojis.
+- The merge request should not contain more than 10 commit messages.
 - Commits that change 30 or more lines across at least 3 files should
   describe these changes in the commit body.
+- The commit subject
+   - and body must be separated by a blank line.
+   - must start with a capital letter.
+   - should contain at least 3 words.
+   - must not be longer than 72 characters.
+   - must not end with a period.
+- The commit body
+   - must not contain more than 72 characters per line.
+   - or subject must not contain Emojis.
 - Use issues and merge requests' full URLs instead of short references,
   as they are displayed as plain text outside of GitLab.
-- The merge request should not contain more than 10 commit messages.
-- The commit subject should contain at least 3 words.
 
 **Important notes:**
 
@@ -205,25 +207,17 @@ requirements.
 
 ### MR Merge
 
+what it does...
+
+#### Description
+
 1. Clear title and description explaining the relevancy of the contribution.
+1. Description includes any steps or setup required to ensure reviewers can view the changes you've made (for example, include any information about feature flags).
 1. Working and clean code that is commented where needed.
 1. The change is evaluated to [limit the impact of far-reaching work](https://about.gitlab.com/handbook/engineering/development/#reducing-the-impact-of-far-reaching-work).
-1. Testing:
-
-   - [Unit, integration, and system tests](../testing_guide/index.md) that all pass
-     on the CI server.
-   - Peer member testing is optional but recommended when the risk of a change is high.
-     This includes when the changes are [far-reaching](https://about.gitlab.com/handbook/engineering/development/#reducing-the-impact-of-far-reaching-work)
-     or are for [components critical for security](../code_review.md#security).
-   - Description includes any steps or setup required to ensure reviewers can view the changes you've made (for example, include any information about feature flags).
-   - Regressions and bugs are covered with tests that reduce the risk of the issue happening
-     again.
-   - For tests that use Capybara, read
-     [how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara).
-   - [Black-box tests/end-to-end tests](../testing_guide/testing_levels.md#black-box-tests-at-the-system-level-aka-end-to-end-tests)
-     added if required. Please contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams)
-     with any questions.
-   - The change is tested in a review app where possible and if appropriate.
+
+#### Functionality
+
 1. In case of UI changes:
 
    - Use available components from the GitLab Design System,
@@ -231,24 +225,43 @@ requirements.
    - The MR must include *Before* and *After* screenshots if UI changes are made.
    - If the MR changes CSS classes, please include the list of affected pages, which
      can be found by running `grep css-class ./app -R`.
+
+1. If your merge request adds new validations to existing models, to make sure the
+   data processing is backwards compatible:
+
+   - Ask in the [`#database`](https://gitlab.slack.com/archives/CNZ8E900G) Slack channel
+     for assistance to execute the database query that checks the existing rows to
+     ensure existing rows aren't impacted by the change.
+   - Add the necessary validation with a feature flag to be gradually rolled out
+     following [the rollout steps](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#rollout).
+
+#### Testing
+
+1. [Unit, integration, and system tests](../testing_guide/index.md) that all pass
+   on the CI server.
+1. Peer member testing is optional but recommended when the risk of a change is high.
+   This includes when the changes are [far-reaching](https://about.gitlab.com/handbook/engineering/development/#reducing-the-impact-of-far-reaching-work)
+   or are for [components critical for security](../code_review.md#security).
+1. Regressions and bugs are covered with tests that reduce the risk of the issue happening
+   again.
+1. For tests that use Capybara, read
+   [how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara).
+1. [Black-box tests/end-to-end tests](../testing_guide/testing_levels.md#black-box-tests-at-the-system-level-aka-end-to-end-tests)
+   added if required. Please contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams)
+   with any questions.
+1. The change is tested in a review app where possible and if appropriate.
+
 1. If your MR touches code that executes shell commands, reads or opens files, or
    handles paths to files on disk, make sure it adheres to the
    [shell command guidelines](../shell_commands.md)
 1. [Code changes should include observability instrumentation](../code_review.md#observability-instrumentation).
 1. If your code needs to handle file storage, see the [uploads documentation](../uploads/index.md).
 1. If your merge request adds one or more migrations:
+
    - Make sure to execute all migrations on a fresh database before the MR is reviewed.
      If the review leads to large changes in the MR, execute the migrations again
      after the review is complete.
    - Write tests for more complex migrations.
-1. If your merge request adds new validations to existing models, to make sure the
-   data processing is backwards compatible:
-
-   - Ask in the [`#database`](https://gitlab.slack.com/archives/CNZ8E900G) Slack channel
-     for assistance to execute the database query that checks the existing rows to
-     ensure existing rows aren't impacted by the change.
-   - Add the necessary validation with a feature flag to be gradually rolled out
-     following [the rollout steps](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#rollout).
 
    If this merge request is urgent, the code owners should make the final call on
    whether reviewing existing rows should be included as an immediate follow-up task
@@ -264,6 +277,9 @@ requirements.
 1. [Performance guidelines](../merge_request_performance_guidelines.md) have been followed.
 1. [Secure coding guidelines](https://gitlab.com/gitlab-com/gl-security/security-guidelines) have been followed.
 1. [Application and rate limit guidelines](../merge_request_application_and_rate_limit_guidelines.md) have been followed.
+
+#### Documentation
+
 1. [Documented](../documentation/index.md) in the `/doc` directory.
 1. [Changelog entry added](../changelog.md), if necessary.
 1. If your merge request introduces changes that require additional steps when