GH-385: Simplify the PR template

[sampoturve]

Ticket

#385

Description

This PR is using the new simpler template 🌿

• Removed 'Best practices' section for being redundant
• Add square brackets for all the texts that should be replaced, to make it clearer on what to update
• This template will still have the MD041/first-line-heading/first-line-h1: First line in a file should be a top-level heading linting error, but IMO it doesn't make any sense to add level 1 heading here just for the sake of it.

One thing I'd still consider removing is the Setting up local environment section, as I think those steps should be added under Testing instructions section, even though the instructions can be used for both local and feature environment testing.

Testing

Feature environment

No feature environment.

Setting up local environment

No local environment setting up required.

Testing instructions

See that the PR template makes sense.

[tormi]

What about even simpler approach?

Ticket GH-406

Changes

• Simplify Drupal project template pull request template

Testing

Environment: https://environment.tld

Checks

• check if template follows the KISS principle
• check if headings are sized hierarchically
• ...

Markdown:

## Ticket GH-406

### Changes

- Simplify Drupal project template pull request template

### Testing

Environment: https://environment.tld

#### Checks

- [ ] check if headings are sized hierarchically
- [ ] check if template follows the [KISS principle](https://en.wikipedia.org/wiki/KISS_principle)
- [ ] ...

[tormi]

Another template with really important topics:

• type of change select checks
• documentation update check
• testing coverage checks

There's also an interesting feature assignees implemented.

assignees: 'BrianGilbert'
<!--- Provide a general summary of your changes in the title above -->

## Types of changes
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
- [ ] Bug fix (a non-breaking change which fixes an issue)
- [ ] New feature (a non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)


## Description
<!--- Describe your changes in detail -->
<!--- Why is this change required? What problem does it solve? -->
<!--- If it resolves an open issue, please link to the issue here. For example "Resolves: #1337" -->


## Checklist:
<!--- Put an `x` in all the boxes that apply. -->
<!--- If your change requires a documentation PR, please link it appropriately -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes (if not applicable, please state why)
- [ ] All new and existing tests are passing.


## Screenshots/Media:
<!--- Add any screenshots or other type of media to demonstrate your change -->

Source: https://github.com/Realityloop/foundry/blob/develop/.github/PULL_REQUEST_TEMPLATE.md

[sampoturve]

Adding the ticket link into the title could be an option, but IMO it's way easier to simply copy-paste the URL under a certain heading instead of needing to do some formatting in the way of ## Ticket [GH-385](https://github.com/wunderio/drupal-project/pull/385). I guess many projects have the auto-linking by ID though, so I could be in the minority.

I maybe wouldn't go with the checklists, as checking and reordering those seem to be global and in cases where there are multiple reviewers, those might bring more confusion than benefit.

The latter example looks quite good though. The HTML comments are a nice touch, but I think those would be mostly useful for someone that isn't that accustomed to creating PRs. Would the comments then be in the way of someone that's more experieced, I don't know. Balancing act, this ⚖️