Proposal to remove some ambiguity from MR template checklists

Problem

Some ambiguity was identified in !17676 (comment 224751312). It's best to remove ambiguity if possible.

Checking them off seems to imply that the MR contains changes that require those to-do items. If checking means assessing if the to-do item needs to be done, then I'm ok with making that change to the description.

Proposal

  • Add the following below ## Does this MR meet the acceptance criteria?:
<!--

- [x] means it has been assessed, and is satisfied
- [-] means it has been assessed, and is irrelevant (deletion doesn't leave room for reconsideration, or becoming relevant after a change)
- [ ] means it has not been assessed, or it is not satisfied yet

-->
  • Add the following below ### Conformity:
This MR conforms to:
  • Remove checkboxes from guideline docs
- [Code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
- [Merge request performance guidelines](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [Style guides](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/development/contributing/style_guides.md)
- [Database guides](https://docs.gitlab.com/ee/development/README.html#database-guides)
  • Remove the following from the ### Performance and Testing section:
<!-- If cross-browser testing is not required, please remove the relevant item, or mark it as not needed: [-] -->

Result

## What does this MR do?

<!--

Describe in detail what your merge request does and why.

Are there any risks involved with the proposed change? What additional
test coverage is introduced to offset the risk?

Please keep this description up-to-date with any discussion that takes
place so that reviewers can understand your intent. This is especially
important if they didn't participate in the discussion.

-->

## Screenshots

<!-- Please include any relevant screenshots that will assist reviewers and future readers -->

## Does this MR meet the acceptance criteria?

<!--

- [x] means it is relevant and has been satisfied
- [ ] means it has not been assessed, or it does not conform yet
- [-] means it is irrelevant

Take care when deleting items, since it doesn't leave room for reconsideration, or becoming relevant after a change.

-->

### Conformity

This MR conforms to:

- [Code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
- [Merge request performance guidelines](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [Style guides](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/development/contributing/style_guides.md)
- [Database guides](https://docs.gitlab.com/ee/development/README.html#database-guides)
- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) 
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html) or [follow-up review issue created](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review)
- [ ] [Separation of EE specific content](https://docs.gitlab.com/ee/development/ee_features.html#separation-of-ee-code)

### Performance and Testing

<!-- What risks does this change pose? How might it affect the quality/performance of the product?
What additional test coverage or changes to tests will be needed?
Will it require cross-browser testing?
See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ -->

- [ ] [Review and add/update tests for this feature/bug](https://docs.gitlab.com/ee/development/testing_guide/index.html). Consider [all test levels](https://docs.gitlab.com/ee/development/testing_guide/testing_levels.html). See the [Test Planning Process](https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/).
- [ ] [Tested in all supported browsers](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)

### Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in [the security review guidelines](https://about.gitlab.com/handbook/engineering/security/#when-to-request-a-security-review):

- [ ] Label as ~security and @ mention `@gitlab-com/gl-security/appsec`
- [ ] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [ ] Security reports checked/validated by a reviewer from the AppSec team
Edited by Michael Kozono