HeartSaVioR edited a comment on pull request #28403: URL: https://github.com/apache/spark/pull/28403#issuecomment-621155094
It sounds like non-minor thing which worths to initiate discussion. From my experience, first two sections have been ended up describing the similar things, hence many times I just mentioned that previous/next section describes it. I'm also wondering about the benefits of being strict about the section `Does this PR introduce any user-facing change?`. This seems to be adopted from Kubernetes, but after I looked into Kubernetes template, the meaning of the section looks to be very different. https://raw.githubusercontent.com/kubernetes/kubernetes/master/.github/PULL_REQUEST_TEMPLATE.md ``` **Special notes for your reviewer**: **Does this PR introduce a user-facing change?**: <!-- If no, just write "NONE" in the release-note block below. If yes, a release note is required: Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required". For more information on release notes see: https://git.k8s.io/community/contributors/guide/release-notes.md --> \```release-note \``` **Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.**: <!-- This section can be blank if this pull request does not require a release note. When adding links which point to resources within git repositories, like KEPs or supporting documentation, please reference a specific commit and avoid linking directly to the master branch. This ensures that links reference a specific point in time, rather than a document that may change over time. See here for guidance on getting permanent links to files: https://help.github.com/en/articles/getting-permanent-links-to-files Please use the following format for linking documentation: - [KEP]: <link> - [Usage]: <link> - [Other doc]: <link> --> \```docs \``` ``` It would be mostly NONE, and require description only when the change worths to put into release note. I personally find the section useful to describe breaking backward compatibility, guide reviewers to focus more on the change, but if we need to put the information for any changes being shown to users (even doc) then it would become the huge pain. Have we gone through the PR template or contribution guide doc for similar size of open source projects? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
