Merge branch 'fix/make_docs_consistent' into 'master'

Make the MR templates more consistent

See merge request gitlab-org/gitlab!75992

.gitlab/merge_request_templates/Change Documentation Location.md

@@ -24,7 +24,7 @@ https://docs.gitlab.com/ee/development/documentation/index.html#move-or-rename-a
       specifically under the `app/views/` and `ee/app/views` (for GitLab EE) directories.
 - [ ] Make sure to add [`redirect_from`](https://docs.gitlab.com/ee/development/documentation/index.html#redirections-for-pages-with-disqus-comments)
       to the new document if there are any Disqus comments on the old document thread.
-- [ ] Update the link in `features.yml` (if applicable)
+- [ ] Update the link in `features.yml` (if applicable).
 - [ ] Assign one of the technical writers for review.
 
 /label ~documentation ~"Technical Writing"

.gitlab/merge_request_templates/Deprecations.md

@@ -41,7 +41,7 @@ They are frequently updated, and everyone should make sure they are aware of the
 
 ## Reviewers
 
-When the content is ready for review, it must be reviewed by Technical Writer and Engineering Manager, but can also be reviewed by
+When the content is ready for review, it must be reviewed by a Technical Writer and Engineering Manager, but can also be reviewed by
 Product Marketing, Product Design, and the Product Leaders for this area. Please use the
 [Reviewers for Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/getting_started#reviewer)
 feature for all reviews. Reviewers will then `approve` the MR and remove themselves from Reviewers when their review is complete.
@@ -61,7 +61,7 @@ as needed, @ message the PM to inform them the first review is complete, and rem
 yourself as a reviewer if it's not ready for merge yet.
 
 <details>
-<summary>Expand for Details </summary>
+<summary>Expand for Details</summary>
 
 - [ ] Title:
   - Length limit: 7 words (not including articles or prepositions).

.gitlab/merge_request_templates/Documentation.md

@@ -8,7 +8,7 @@
 
 ## Author's checklist
 
-- [ ] Consider taking [the GitLab Technical Writing Fundamentals course](https://gitlab.edcast.com/pathways/ECL-02528ee2-c334-4e16-abf3-e9d8b8260de4)
+- [ ] Consider taking [the GitLab Technical Writing Fundamentals course](https://gitlab.edcast.com/pathways/ECL-02528ee2-c334-4e16-abf3-e9d8b8260de4).
 - [ ] Follow the:
   - [Documentation process](https://docs.gitlab.com/ee/development/documentation/workflow.html).
   - [Documentation guidelines](https://docs.gitlab.com/ee/development/documentation/).
@@ -40,7 +40,7 @@ Documentation-related MRs should be reviewed by a Technical Writer for a non-blo
     - [ ] The headings (other than the page title) should be active. Instead of `Configuring GDK`, say something like `Configure GDK`.
     - [ ] Any task steps should be written as a numbered list.
     - If the content still needs to be edited for topic types, you can create a follow-up issue with the ~"docs-technical-debt" label.
-- [ ] Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
+- [ ] Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.
 - [ ] Ensure a release milestone is set.
 
 /label ~documentation ~"type::maintenance"

.gitlab/merge_request_templates/New End To End Test.md

@@ -4,7 +4,7 @@
 Please link to the respective test case in the testcases project
 -->
 
-### Check-list
+### Checklist
 
 - [ ] Confirm the test has a [`testcase:` tag linking to an existing test case](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/best_practices.html#link-a-test-to-its-test-case-issue) in the test case project.
 - [ ] Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario.
@@ -15,7 +15,7 @@ Please link to the respective test case in the testcases project
 - [ ] Verify the tags to ensure it runs on the desired test environments.
 - [ ] If this MR has a dependency on another MR, such as a GitLab QA MR, specify the order in which the MRs should be merged.
 - [ ] (If applicable) Create a follow-up issue to document [the special setup](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/running_tests_that_require_special_setup.html) necessary to run the test: ISSUE_LINK
-- [ ] If the test requires an admin's personal access token, ensure that the test passes on your local with and without the `GITLAB_QA_ADMIN_ACCESS_TOKEN` provided.
+- [ ] If the test requires an admin's personal access token, ensure that the test passes on your local environment with and without the `GITLAB_QA_ADMIN_ACCESS_TOKEN` provided.
 
 <!-- Base labels. -->
 /label ~"Quality" ~"QA" ~test

.gitlab/merge_request_templates/New Static Analysis Check.md

@@ -12,20 +12,20 @@ Please describe the proposal and add a link to the source (for example, http://w
 ### Check-list
 
 - [ ] Make sure this MR enables a static analysis check rule for new usage but
-  ignores current offenses
-- [ ] Mention this proposal in the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`)
+  ignores current offenses.
+- [ ] Mention this proposal in the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`).
 - [ ] If there is a choice to make between two potential styles, set up an emoji vote in the MR:
   - CHOICE_A: :a:
   - CHOICE_B: :b:
-  - Vote yourself for both choices so that people know these are the choices
-- [ ] The MR doesn't have significant objections, and is getting a majority of :+1: vs :-1: (remember that [we don't need to reach a consensus](https://about.gitlab.com/handbook/values/#collaboration-is-not-consensus))
-- [ ] (If applicable) One style is getting a majority of vote (compared to the other choice)
-- [ ] (If applicable) Update the MR with the chosen style
+  - Vote for both choices, so they are visible to others.
+- [ ] The MR doesn't have significant objections, and is getting a majority of :+1: vs :-1: (remember that [we don't need to reach a consensus](https://about.gitlab.com/handbook/values/#collaboration-is-not-consensus)).
+- [ ] (If applicable) One style is getting a majority of vote (compared to the other choice).
+- [ ] (If applicable) Update the MR with the chosen style.
 - [ ] Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK
-- [ ] Follow the [review process](https://docs.gitlab.com/ee/development/code_review.html) as usual
+- [ ] Follow the [review process](https://docs.gitlab.com/ee/development/code_review.html) as usual.
 - [ ] Once approved and merged by a maintainer, mention it again:
-  - [ ] In the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`)
-  - [ ] (Optional depending on the impact of the change) In the Engineering Week in Review
+  - [ ] In the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`).
+  - [ ] (Optional depending on the impact of the change) In the Engineering Week in Review.
 
 /label ~"Engineering Productivity" ~"development guidelines" ~"static code analysis"
 

.gitlab/merge_request_templates/Pipeline Configuration.md

@@ -9,7 +9,7 @@
 
 <!-- Link related issues below. -->
 
-## Check-list
+## Checklist
 
 ### Pre-merge
 

.gitlab/merge_request_templates/Security Release.md

@@ -20,13 +20,13 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
   - [ ] Assign to a reviewer and maintainer, per our [Code Review process].
   - [ ] Ensure it's approved according to our [Approval Guidelines].
   - [ ] Ensure it's approved by an AppSec engineer.
-    - Please see the security release [Code reviews and Approvals](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#code-reviews-and-approvals) documentation for details on which AppSec team member to ping for approval.
+    - Please see the security release [Code reviews and Approvals] documentation for details on which AppSec team member to ping for approval.
     - Trigger the [`package-and-qa` build]. The docker image generated will be used by the AppSec engineer to validate the security vulnerability has been remediated.
-- [ ] For a backport MR targeting a versioned stable branch (`X-Y-stable-ee`)
+- [ ] For a backport MR targeting a versioned stable branch (`X-Y-stable-ee`).
   - [ ] Milestone is set to the version this backport applies to. A closed milestone can be assigned via [quick actions].
   - [ ] Ensure it's approved by a maintainer.
 
-**Note:** Reviewer/maintainer should not be a Release Manager
+**Note:** Reviewer/maintainer should not be a Release Manager.
 
 ## Maintainer checklist
 
@@ -39,6 +39,7 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
 [quick actions]: https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics
 [CHANGELOG entry]: https://docs.gitlab.com/ee/development/changelog.html#overview
 [Code Review process]: https://docs.gitlab.com/ee/development/code_review.html
+[Code reviews and Approvals]: (https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#code-reviews-and-approvals)
 [Approval Guidelines]: https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines
 [Canonical repository]: https://gitlab.com/gitlab-org/gitlab
 [`package-and-qa` build]: https://docs.gitlab.com/ee/development/testing_guide/end_to_end/#using-the-package-and-qa-job