[aeruhxi]

Description:

Aligns the shared PR template with https://github.com/Kittl/mono/pull/15939

How to test:

• After merge, open a PR in a Kittl repo without its own template and check that the new sections show up.

Checklist (based on PR guidelines):

• I have self-reviewed this PR, according to these points
• This PR falls into maximum three of these categories
• I feel comfortable taking responsibility for merging this code to production
• The code is high quality, well-tested, follows styles guides (Frontend), clean, and well documented

[claas-c]

not everything is an issue, would phrase it more general.
I wouldn't put a hard restriction to exclude tests, some PR are best "tested" by running a certain test before and after and see the difference from that

[aeruhxi]

not everything is an issue, would phrase it more general.

I agree

I wouldn't put a hard restriction to exclude tests, some PR are best "tested" by running a certain test before and after and see the difference from that

I do not understand this. Tests are already adjusted to pass if your PR is ready for review. Or, do you mean adjusting the runtime logic while preserving the newer tests and intentionally failing the test so we can verify that the test is catching bugs? If so, then I am in agreement.

[claas-c]

yeah. Whether a test is passing is checked by CI. but for some PRs the best way to test them is to run a specific test under different parameters or just see how test timing is changing. I don't think this is a super recurring case, I would just avoid to put a hard limit on it

[aeruhxi]

Updated both PRs in regards to hard limiting the inclusion of test.