Clarify PR template (#74)

## Describe your changes

As a new contributor you can not actually assign reviewers and asignees
to PRs. But we request this in the PR template:

https://github.com/mllam/neural-lam/blob/4969f92ad974f136089d15e7e2e2e9d73a43590d/.github/pull_request_template.md?plain=1#L29

This change clarifies the PR template to state that you only have to do
this if you are able to. Otherwise we instruct contributors to tag a
maintainer to add reviewer and asignee.

## Issue Link

Solves #73 

## Type of change

- [ ] 🐛 Bug fix (non-breaking change that fixes an issue)
- [ ] ✨ New feature (non-breaking change that adds functionality)
- [ ] 💥 Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [x] 📖 Documentation (Addition or improvements to documentation)

## Checklist before requesting a review

- [x] My branch is up-to-date with the target branch - if not update
your fork with the changes from the target branch (use `pull` with
`--rebase` option if possible).
- [x] I have performed a self-review of my code
- [x] For any new/modified functions/classes I have added docstrings
that clearly describe its purpose, expected inputs and returned values
- [x] I have placed in-line comments to clarify the intent of any
hard-to-understand passages of my code
- [x] I have updated the [README](README.MD) to cover introduced code
changes
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] I have given the PR a name that clearly describes the change,
written in imperative form
([context](https://www.gitkraken.com/learn/git/best-practices/git-commit-message#using-imperative-verb-form)).
- [x] I have requested a reviewer and an assignee (assignee is
responsible for merging)

## Checklist for reviewers

Each PR comes with its own improvements and flaws. The reviewer should
check the following:
- [ ] the code is readable
- [ ] the code is well tested
- [ ] the code is documented (including return types and parameters)
- [ ] the code is easy to maintain

## Author checklist after completed review

- [x] I have added a line to the CHANGELOG describing this change, in a
section
  reflecting type of change (add section where missing):
  - *added*: when you have added new functionality
  - *changed*: when default behaviour of the code has been changed
  - *fixes*: when your contribution fixes a bug

## Checklist for assignee

- [x] PR is up to date with the base branch
- [x] the tests pass
- [x] author has added an entry to the changelog (and designated the
change as *added*, *changed* or *fixed*)
- Once the PR is ready to be merged, squash commits and merge the PR.

.github/pull_request_template.md

@@ -26,7 +26,7 @@
 - [ ] I have updated the [README](README.MD) to cover introduced code changes
 - [ ] I have added tests that prove my fix is effective or that my feature works
 - [ ] I have given the PR a name that clearly describes the change, written in imperative form ([context](https://www.gitkraken.com/learn/git/best-practices/git-commit-message#using-imperative-verb-form)).
-- [ ] I have requested a reviewer and an assignee (assignee is responsible for merging)
+- [ ] I have requested a reviewer and an assignee (assignee is responsible for merging). This applies only if you have write access to the repo, otherwise feel free to tag a maintainer to add a reviewer and assignee.
 
 ## Checklist for reviewers
 

CHANGELOG.md

@@ -35,6 +35,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Changed
 
+- Clarify routine around requesting reviewer and assignee in PR template
+  [\#74](https://github.com/mllam/neural-lam/pull/74)
+  @joeloskarsson
+
 - Argument Parser updated to use action="store_true" instead of 0/1 for boolean arguments.
   (https://github.com/mllam/neural-lam/pull/72)
   @ErikLarssonDev