Respectfully, I disagree. I believe PRs are the wrong place for this information. Once you merge this how do you ever find it again? I'm looking at the code in an editor 99% of the time. There is no context to this PR there. I would have to git blame the file then parse through all of the changes then go find the relevant PR.
A much better place for this information is in ADRs committed to the repo.
Document your Architectural Decisions in ADRs.
Document your code changes in your PR.
I think the Context section is great, but the Context and Description can be folded into one section. Plus I would add a testing/assertion plan to this, where it outlines how you assert that this PR does what it says. i.e. Log in, go to page, click thing see X. (Note this is separate from any automated testing. I want to know as a reviewer how do I personally confirm that what you're saying you did actually works)
That give me much more context as a reviewer and it forces your devs to not be lazy and not check their code before committing.
IMHO large boilerplate templates like this result in skimming and hand waving.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Respectfully, I disagree. I believe PRs are the wrong place for this information. Once you merge this how do you ever find it again? I'm looking at the code in an editor 99% of the time. There is no context to this PR there. I would have to git blame the file then parse through all of the changes then go find the relevant PR.
A much better place for this information is in ADRs committed to the repo.
Document your Architectural Decisions in ADRs.
Document your code changes in your PR.
I think the Context section is great, but the Context and Description can be folded into one section. Plus I would add a testing/assertion plan to this, where it outlines how you assert that this PR does what it says. i.e. Log in, go to page, click thing see X. (Note this is separate from any automated testing. I want to know as a reviewer how do I personally confirm that what you're saying you did actually works)
That give me much more context as a reviewer and it forces your devs to not be lazy and not check their code before committing.
IMHO large boilerplate templates like this result in skimming and hand waving.