Yes, that’s the hard thing about having a “what changed” section in the PR template. I agree with you, but generally put a very condensed summary of what changed to fulfill the PR template expectations. Not the worst compromise

▲

SAI_Peregrinus 10 days ago | parent | next [-]

My template:

1. What is this change supposed to do?

2. Why is this change needed?

3. How was it tested?

4. Is there anything else reviewers should know?

5. Link to issue:

There's no "What changed?" because that's the diff. Explain your intent, why you think it's a good idea, how you know you accomplished your intent, and any future work needed or other concerns noticed while making the change. PR descriptions suffer from the same problem as code comments by beginners: they often just describe the "what" when that's obvious from the code, when the "why" is what's needed. So try very hard to avoid doing that.

	▲	mafuy 9 days ago \| parent [-]
		It's same same issue we had 20 years ago with javadoc. Write what you want to do, not how you do it. i++; // increment i (by 1)

▲

collingreen 10 days ago | parent | prev [-]

My PR templates are: - what CONCEPTUALLY changed here and why - a checklist that asserts the author did in fact run their code and the tests and the migrations and other babysitting rules written in blood - explicit lists of database migrations or other changes - explicit lists of cross dependencies - images or video of the change actually working as intended (also patronizing but also because of too many painful failures without it)

Generally small startups after initial pmf. I have no idea how to run a big company and pre pmf Im guilty of "all cowboy, all the time" - YMMV