Hi Spark Developers, There has been a rather active discussion regarding the specific vetoes that occured during Spark 3. From that I believe we are now mostly in agreement that it would be best to clarify our rules around code vetoes & merging in general. Personally I believe this change is important to help improve the appearance of a level playing field in the project.
Once discussion settles I'll run this by a copy editor, my grammar isn't amazing, and bring forward for a vote. The current Spark committer guide is at https://spark.apache.org/committers.html. I am proposing we add a section on when it is OK to merge PRs directly above the section on how to merge PRs. The text I am proposing to amend our committer guidelines with is: PRs shall not be merged during active on topic discussion except for issues like 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. For the purposes of a -1 on code changes, a qualified voter includes all PMC members and committers in the project. For a -1 to be a valid veto it must include a technical reason. The reason can include things like the change may introduce a maintenance burden or is not the direction of Spark. If there is a -1 from a non-committer, multiple committers or the PMC should be consulted before moving forward. If the original person who cast the veto can not be reached in a reasonable time frame given likely holidays, it is up to the PMC to decide the next steps within the guidelines of the ASF. This must be decided by a consensus vote under the ASF voting rules. 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 all parties take the time to build consensus prior to additional feature work. Being a committer means exercising your judgement, while working in a community with diverse views. There is nothing wrong in getting a second (or 3rd or 4th) 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 that makes it easier for us to reach consensus. If you have ideas on how to improve these guidelines, or other parts of how the Spark project operates you should reach out on the dev@ list to start the discussion. 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
