Consider reducing the number of tasks in merge request templates
The number of tasks in our merge request template(s) has been growing in recent months. Many of these tasks are highly situational, resulting in MR authors either having to remove them or ignore them. In case they are ignored this may make reviewing the MR more difficult, as it might not be clear to a reviewer that certain pending tasks can be ignored.
Currently we have the following tasks defined:
- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) added, if necessary
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html) via this MR
- [ ] Documentation reviewed by technical writer *or* follow-up review issue [created](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review)
- [ ] [Tests added for this feature/bug](https://docs.gitlab.com/ee/development/testing_guide/index.html)
- [ ] Tested in [all supported browsers](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)
- [ ] Conforms to the [code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
- [ ] Conforms to the [merge request performance guidelines](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [ ] Conforms to the [style guides](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Conforms to the [database guides](https://docs.gitlab.com/ee/development/README.html#database-guides)
- [ ] Link to e2e tests MR added if this MR has ~"Requires e2e tests" label. See the [Test Planning Process](https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/).
- [ ] Security reports checked/validated by reviewer
The following tasks are very situational:
- [ ] Documentation reviewed by technical writer *or* follow-up review issue [created](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review)
- [ ] Tested in [all supported browsers](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers)
- [ ] Conforms to the [database guides](https://docs.gitlab.com/ee/development/README.html#database-guides)
- [ ] Link to e2e tests MR added if this MR has ~"Requires e2e tests" label. See the [Test Planning Process](https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/).
- [ ] Security reports checked/validated by reviewer
The documentation task is only necessary if you add documentation, which for many MRs is not necessary. Danger will also detect this (to a certain degree) if the MR is submitted from a CE/EE branch.
The browser testing task only makes sense for frontend changes, meaning that for a lot of MRs it just won't apply.
The database task only applies to MRs that make various DB changes. Since this is pretty common, I would probably just merge this into the code review guidelines.
The e2e tests task is one I never figured out. The linked document doesn't do a good job of describing what I should do and when. It's also not clear if I as an author should add Requires e2e tests or if this is done automatically somehow.
The security reports checkbox is redundant. The MR widget shows the security report status, and most of the time this is either OK or reporting something that's unrelated to your MR (e.g. a vulnerability in some Gem somebody else is already taking care of). From what I have seen this usually results in this checkbox just being ignored entirely.
I propose that we either remove or merge the above tasks, cutting down the amount of "task noise" per MR. This means we'd end up with the following:
- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) added, if necessary
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html) via this MR
- [ ] [Tests added for this feature/bug](https://docs.gitlab.com/ee/development/testing_guide/index.html)
- [ ] Conforms to the [code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
- [ ] Conforms to the [merge request performance guidelines](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [ ] Conforms to the [style guides](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/CONTRIBUTING.md#style-guides)