Thanks, guys. Let me probably mimic the template and open a PR soon - currently I am stuck in some works. I will take a look in few days later.
2019년 7월 27일 (토) 오전 3:32, Bryan Cutler <cutl...@gmail.com>님이 작성: > The k8s template is pretty good. Under the behavior change section, it > would be good to add instructions to also describe previous and new > behavior as Hyukjin proposed. > > On Tue, Jul 23, 2019 at 10:07 PM Reynold Xin <r...@apache.org> wrote: > >> I like the spirit, but not sure about the exact proposal. Take a look at >> k8s': >> https://raw.githubusercontent.com/kubernetes/kubernetes/master/.github/PULL_REQUEST_TEMPLATE.md >> >> >> >> On Tue, Jul 23, 2019 at 8:27 PM, Hyukjin Kwon <gurwls...@gmail.com> >> wrote: >> >>> (Plus, it helps to track history too. Spark's commit logs are growing >>> and now it's pretty difficult to track the history and see what change >>> introduced a specific behaviour) >>> >>> 2019년 7월 24일 (수) 오후 12:20, Hyukjin Kwon <gurwls...@gmail.com>님이 작성: >>> >>> Hi all, >>> >>> I would like to discuss about some new sections under "## What changes >>> were proposed in this pull request?": >>> >>> ### Do the changes affect _any_ user/dev-facing input or output? >>> >>> (Please answer yes or no. If yes, answer the questions below) >>> >>> ### What was the previous behavior? >>> >>> (Please provide the console output, description and/or reproducer about the >>> previous behavior) >>> >>> ### What is the behavior the changes propose? >>> >>> (Please provide the console output, description and/or reproducer about the >>> behavior the changes propose) >>> >>> See >>> https://github.com/apache/spark/blob/master/.github/PULL_REQUEST_TEMPLATE >>> . >>> >>> From my experience so far in Spark community, and assuming from the >>> interaction with other >>> committers and contributors, It is pretty critical to know before/after >>> behaviour changes even if it >>> was a bug. In addition, I think this is requested by reviewers often. >>> >>> The new sections will make review process much easier, and we're able to >>> quickly judge how serious the changes are. >>> Given that Spark community still suffer from open PRs just queueing up >>> without review, I think this can help >>> both reviewers and PR authors. >>> >>> I do describe them often when I think it's useful and possible. >>> For instance see https://github.com/apache/spark/pull/24927 - I am sure >>> you guys have clear idea what the >>> PR fixes. >>> >>> I cc'ed some guys I can currently think of for now FYI. Please let me >>> know if you guys have any thought on this! >>> >>> >>
