I think there are may more aspect than just the release notes. Yes we can ask every time for information but that is not a good use of everyone's time. Let the template ask for it.
At the time the PR comes in, the submitter is the "expert in the problem domain". Not the committer. The committers should not have to infer intent or what tradeoffs were made. Set expectations (set em low if you feel it is a burden) but set them. Yes we should help newbies to the project, to write good PR information. Blank canvas's do not do that. The project ambassador can. We can all be ambassador or you can have a decent template do that job. A professional project team should know how to do this, and do it. No excuses. >From this project I have seen really good PR descriptions and no descriptions at all for complex changes. We owe it to each other to share the reason we are changing stuff that others have done and had their reasons for it. Over time, these good PR descriptions will help converge the project and be a recorded of why. David -----Original Message----- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Friday, June 05, 2020 6:44 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] requirements for commit messages and PRs On Thu, Jun 4, 2020 at 7:19 PM Jukka Laitinen <jukka.laiti...@iki.fi> wrote: > But the template in the commit... please, no. I have had enough of those > in big companies and in the end they are just harmful. I agree with that!! We should not be too rigid and complicated. The more I think about it, the more I like Greg's approach. Whoever reviews PRs can write the description or collaborate with the author and write it together. For simple fixes, don't write too much. For changes that affect end users, try to explain how it affects them and what do they need to do? We just want to make better documentation and release notes, not put burden on people. How do our committers feel about that? Are we good with keeping the "Summary, Impact, Testing" template, and just try to make better descriptions together? Nathan
