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
