.github: Add pull request template

[roberth]

Closes #7538

[fricklerhandwerk]

I strongly welcome to introduce a checklist.

Yet, my gut reaction to putting it into the PR description is aversion, but I can't immediately say why exactly.

I'll try to pick it apart with considerations and possible alternatives:

• like in Nixpkgs, use labels to express required tasks and PR state
  • this has some potential drawbacks, such as information on what the labels mean only being visible somewhere else
• including a checklist in the PR description introduces noise for PR authors
  • maybe indeed adding an action that posts it immediately as a comment is better
• the checklist could be in the maintainer/contributor guide and we just work it off as a routine
  • this has a similar disadvantage of living in a different place than where the action happens, but would be close to other information for contributors
• a combination of the above, such as a checklist in the manual, a team routine to add labels during review, and a (set of) action(s) to act on the labels in order to produce notifications that carry more context
  • for example, if maintainers add a label "needs release notes", after some delay the bot would post a friendly comment addressed to the author to add release notes, including a link to the checklist in the manual. when the branch is updated to change release notes, that label is replaced by "has release notes"

[roberth]

I agree that it's not optimal, but I do think it's an improvement. It's a simple solution, and I am not eager to experiment with labels and actions.
A manual process is the status quo and it's too easy to use it improperly or forget it completely.

including a checklist in the PR description introduces noise for PR authors

It is also a reminder of what the criteria for a good pr are. Surely not all, but at least some contributors will try to comply with the checkboxes when they see them. That helps everyone achieve their goals.

after some delay the bot would post a friendly comment

Any delay will make the contributor have to revisit the PR. Often the change is easy to make when you're still working on it, but it takes energy to revisit it and switch contexts.

[fricklerhandwerk]

@roberth agreed, having something is better than nothing. Made some suggestions how to make it more precise and hopefully more useful.

Maybe in the long run we should provide links to materials that go more into detail what a good contribution looks like and why that's so. One that comes to mind, because I was involved in reviewing it is Getting Things Merged by @smelc, but there are surely more, other high quality texts on different aspects of the process.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-team-report-2022-10-2023-03/27486/1