Hi Holden, thanks for leading this discussion, I'm in favor in general. I have one specific question -- these two sections seem to contradict each other slightly:
> 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. I think the intent here is that if a *committer* gives a -1, then the PMC has to have a consensus vote? And if a non-committer gives a -1, then multiple committers should be consulted? How about combining those two into something like "All -1s with justification merit discussion. A -1 from a non-committer can be overridden only with input from multiple committers. A -1 from a committer requires a consensus vote of the PMC under ASF voting rules". thanks, Imran On Tue, Jul 21, 2020 at 3:41 PM Holden Karau <hol...@pigscanfly.ca> wrote: > 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 >
