Yes. Simplicity is single most important thing. The entire template
should fit entirely within the PR comment window. It should not be a
punishment to contributors to the project. We will get a better
response if it is simple and usable. No inline instructions, please.
There should not be no more then 3 or possible 4 sections. Users should
be able to fill out the template with what they already know.
I would be better to have no template at all than that ugly, repulsive
one that has been proposed. I like you idea fine. I think Summay,
changes, Release Notes are all trying to get to the same thing. A
simple function description is what is needed... that answers all of those.
Impact is optional, but it is nice to know if anything else is affected
by the change. You gotta admit:
## Summary
## Impact
## Testing
Is pretty damn good! Perhaps "Functional Description of Change" is
better. Perhaps "Affected Behaviors" is better than "Impact". Testing
is intentionally vagues.
Greg
On 6/4/2020 10:23 AM, Nathan Hartman wrote:
On Thu, Jun 4, 2020 at 11:54 AM Gregory Nutt <spudan...@gmail.com> wrote:
See
https://github.com/nuttx-to-asf/incubator-nuttx/commit/b496ee7ff9adeaa9020e7b07efed8198d4e8e623
The is HORRIBLE!!!!!!!!!!! God help us.
Full disclosure: I am the guy with the "lack of working project
experience and vision" who correct that original, horrible template.
I did that with full support and encourgment of all the other people
"lack of working project experience and vision" that I spoke to. The
current template is based on the template used by Sony. I for one, and
I suspect may others, with vote against such an abomination of a template.
I think we should keep the template simple. If it's too complicated,
or too many things to fill out, no one will do it.
Currently we have three headings:
## Summary
## Impact
## Testing
Maybe that should be changed to:
## Changes
## Release Notes
## Testing
The purpose of these sections:
## Changes
Document the change from a NuttX developer's perspective. (In the
past, this went into the CHANGES file.)
## Release Notes
Proposed text for the next version's release notes, to document the
change from a user's perspective.
## Testing
Explain what (if anything) you did to test the changes.
But all of this is worthless if the committers don't enforce it. If a
PR lacks these sections filled in, the committers who review it should
request it to be filled in.
Nathan
