+1 Thanks, Mridul
On Thu, Jul 30, 2020 at 4:49 PM Holden Karau <hol...@pigscanfly.ca> wrote: > Hi Spark Developers, > > After the discussion of the proposal to amend Spark committer guidelines, > it appears folks are generally in agreement on policy clarifications. (See > https://lists.apache.org/thread.html/r6706e977fda2c474a7f24775c933c2f46ea19afbfafb03c90f6972ba%40%3Cdev.spark.apache.org%3E, > as well as some on the private@ list for PMC.) Therefore, I am calling > for a majority VOTE, which will last at least 72 hours. See the ASF voting > rules for procedural changes at > https://www.apache.org/foundation/voting.html. > > The proposal is to add a new section entitled “When to Commit” to the > Spark committer guidelines, currently at > https://spark.apache.org/committers.html. > > ** START OF CHANGE ** > > PRs shall not be merged during active, on-topic discussion unless they > address issues such as critical security fixes of a public vulnerability. > Under extenuating circumstances, PRs may be merged during active, off-topic > discussion and the discussion directed to a more appropriate venue. Time > should be given prior to merging for those involved with the conversation > to explain if they believe they are on-topic. > > Lazy consensus requires giving time for discussion to settle while > understanding that people may not be working on Spark as their full-time > job and may take holidays. It is believed that by doing this, we can limit > how often people feel the need to exercise their veto. > > All -1s with justification merit discussion. A -1 from a non-committer > can be overridden only with input from multiple committers, and suitable > time must be offered for any committer to raise concerns. A -1 from a > committer who cannot be reached requires a consensus vote of the PMC under > ASF voting rules to determine the next steps within the ASF guidelines for > code vetoes ( https://www.apache.org/foundation/voting.html ). > > These policies serve to reiterate the core principle that code must not be > merged with a pending veto or before a consensus has been reached (lazy or > otherwise). > > It is the PMC’s hope that vetoes continue to be infrequent, and when they > occur, that all parties will take the time to build consensus prior to > additional feature work. > > Being a committer means exercising your judgement while working in a > community of people with diverse views. There is nothing wrong in getting a > second (or third or fourth) opinion when you are uncertain. Thank you for > your dedication to the Spark project; it is appreciated by the developers > and users of Spark. > > It is hoped that these guidelines do not slow down development; rather, by > removing some of the uncertainty, the goal is to make it easier for us to > reach consensus. If you have ideas on how to improve these guidelines or > other Spark project operating procedures, you should reach out on the dev@ > list to start the discussion. > > ** END OF CHANGE TEXT ** > > I want to thank everyone who has been involved with the discussion leading > to this proposal and those of you who take the time to vote on this. I look > forward to our continued collaboration in building Apache Spark. > > I believe we share the goal of creating a welcoming community around the > project. On a personal note, it is my belief that consistently applying > this policy around commits can help to make a more accessible and welcoming > community. > > Kind Regards, > > Holden > > > -- > Twitter: https://twitter.com/holdenkarau > Books (Learning Spark, High Performance Spark, etc.): > https://amzn.to/2MaRAG9 <https://amzn.to/2MaRAG9> > YouTube Live Streams: https://www.youtube.com/user/holdenkarau >
