chore: Revise pull request request template

[MeraX]

Description

The new PR template puts the information content before the checklist. This simplifies the merging process when including the PR description in the merge commit message.

Intent

Implementing this template together with setting the "Default commit message" to "Pull request title and description" provides a comprehensive git history.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Code Compatibility

• I have performed a self-review of my code

Code Performance and Testing

• I have added tests that prove my fix is effective or that my feature works
• I ran the complete Pytest test suite locally, and they pass
• I have tested the changes on a single GPU
• I have tested the changes on multiple GPUs / multi-node setups
• I have run the Benchmark Profiler against the old version of the code
• If the new feature introduces modifications at the config level, I have made sure to update Pydantic Schemas and default configs accordingly

Dependencies

• I have ensured that the code is still pip-installable after the changes and runs
• I have tested that new dependencies themselves are pip-installable.
• I have not introduced new dependencies in the inference portion of the pipeline

Documentation

• My code follows the style guidelines of this project
• I have updated the documentation and docstrings to reflect the changes
• I have added comments to my code, particularly in hard-to-understand areas

Additional Review Notes

Review Process

• Upon merging this PR, please review the commit message and remove any PR checklists. The commit message should provide a clear explanation of the purpose and intent behind the changes introduced in the commit.

[anaprietonem]

Hello Marek! thanks for the PR! While thinking about this, I thought an option to remove the need for the manual process would be to 'detach' the checklist from the PR template and add that as github action by which when opening a PR, a 'bot' would comment on the PR the checklist for reviewers and developers to go through it. That way, we could keep a more meaningful github commit history without introducing a manual process as part of our development. What do you think?

[MeraX]

Ana, that is a very good solution. Can you check TODOs in my comment? This would also increase the user experience, as I find it always a bit tedious to enter Xes by hand.

• Yes

[anaprietonem]

Ana, that is a very good solution. Can you check TODOs in my comment? This would also increase the user experience, as I find it always a bit tedious to enter Xes by hand.

• Yes

Yes I could click on that TODO without any problem!

[mchantry]

How does Intent differ from Description?

[MeraX]

I believe well-crafted commit messages provide context by addressing the following questions:

1. What changes have been introduced?
2. What problem does this change solve?
3. What issue or task does this change relate to?

I would answer these questions under the headings 'Description', 'Intent', and 'Issue Number'. But perhaps you could suggest clearer headings. What about replacing the current instructions given as <!-- comments --> by these questions? Would that ease the template?

[mchantry]

Thanks Marek. Particularly for 1 & 2 I wonder if these should not be the actual headings? If not, perhaps hidden as comments is also useful.

[MeraX]

good idea.

[anaprietonem]

@MeraX we discussed this with the team, the creation of an additional ci workflow might be cumbersome so we could opt to simplify the PR template, and rather than having 'tick' boxes use the questions or headers we currently have, plus a reminder or responsibility note at the bottom to remind both reviewers and developers about dependencies, tests and testing their code with multiple gpus/node.

Description

What issue or task does this change relate to?

What problem does this change solve?

Describe if it's a bugfix, new feature, doc update, or breaking change

What issue or task does this change relate to?

link to Issue Number

Additional notes

As a contributor to the Anemoi framework, please ensure that your changes include unit tests, updates to any affected dependencies and documentation, and have been tested in a parallel setting (i.e., with multiple GPUs). As a reviewer, you are also responsible for verifying these aspects and requesting changes if they are not adequately addressed.

The last bit would be repeated in the commit message for each PR, but this would simplify our workflow across all the anemoi packages.

[MeraX]

Ana, please go ahead and push your suggestion to this branch.