+1
Tom
On Tuesday, July 21, 2020, 03:35:18 PM CDT, 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
YouTube Live Streams: https://www.youtube.com/user/holdenkarau
