Re: [VOTE] Update the committer guidelines to clarify when to commit changes.

[Holden Karau]

This vote passes with only +1s. In conjunction with the discussion I
believe we have consensus. I will update the website this week with the
proposed change. Thank you all for your participation.

On Sun, Aug 2, 2020 at 9:33 PM Prashant Sharma  wrote:

> +1
>
> On Fri, Jul 31, 2020 at 10:18 PM Xiao Li  wrote:
>
>> +1
>>
>> Xiao
>>
>> On Fri, Jul 31, 2020 at 9:32 AM Mridul Muralidharan 
>> wrote:
>>
>>>
>>> +1
>>>
>>> Thanks,
>>> Mridul
>>>
>>> On Thu, Jul 30, 2020 at 4:49 PM Holden Karau 
>>> 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  
 YouTube Live Streams: https://www.youtube.com/user/holdenkarau

>>>
>>
>> --
>> 
>>
> --
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

Re: [VOTE] Update the committer guidelines to clarify when to commit changes.

[Prashant Sharma]

+1

On Fri, Jul 31, 2020 at 10:18 PM Xiao Li  wrote:

> +1
>
> Xiao
>
> On Fri, Jul 31, 2020 at 9:32 AM Mridul Muralidharan 
> wrote:
>
>>
>> +1
>>
>> Thanks,
>> Mridul
>>
>> On Thu, Jul 30, 2020 at 4:49 PM Holden Karau 
>> 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  
>>> YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>>>
>>
>
> --
> 
>

Re: [VOTE] Update the committer guidelines to clarify when to commit changes.

[Xiao Li]

+1

Xiao

On Fri, Jul 31, 2020 at 9:32 AM Mridul Muralidharan 
wrote:

>
> +1
>
> Thanks,
> Mridul
>
> On Thu, Jul 30, 2020 at 4:49 PM Holden Karau  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  
>> YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>>
>

-- 

Re: [VOTE] Update the committer guidelines to clarify when to commit changes.

[Mridul Muralidharan]

+1

Thanks,
Mridul

On Thu, Jul 30, 2020 at 4:49 PM Holden Karau  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  
> YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>

Re: [VOTE] Update the committer guidelines to clarify when to commit changes.

[Shivaram Venkataraman]

+1

Thanks
Shivaram

On Thu, Jul 30, 2020 at 11:56 PM Wenchen Fan  wrote:
>
> +1, thanks for driving it, Holden!
>
> On Fri, Jul 31, 2020 at 10:24 AM Holden Karau  wrote:
>>
>> +1 from myself :)
>>
>> On Thu, Jul 30, 2020 at 2:53 PM Jungtaek Lim  
>> wrote:
>>>
>>> +1 (non-binding, I guess)
>>>
>>> Thanks for raising the issue and sorting it out!
>>>
>>> On Fri, Jul 31, 2020 at 6:47 AM Holden Karau  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
 YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>>
>>
>>
>> --
>> 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

-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

Re: [VOTE] Update the committer guidelines to clarify when to commit changes.

[Wenchen Fan]

+1, thanks for driving it, Holden!

On Fri, Jul 31, 2020 at 10:24 AM Holden Karau  wrote:

> +1 from myself :)
>
> On Thu, Jul 30, 2020 at 2:53 PM Jungtaek Lim 
> wrote:
>
>> +1 (non-binding, I guess)
>>
>> Thanks for raising the issue and sorting it out!
>>
>> On Fri, Jul 31, 2020 at 6:47 AM Holden Karau 
>> 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  
>>> YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>>>
>>
>
> --
> 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
>

Re: [VOTE] Update the committer guidelines to clarify when to commit changes.

[Holden Karau]

+1 from myself :)

On Thu, Jul 30, 2020 at 2:53 PM Jungtaek Lim 
wrote:

> +1 (non-binding, I guess)
>
> Thanks for raising the issue and sorting it out!
>
> On Fri, Jul 31, 2020 at 6:47 AM Holden Karau  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  
>> YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>>
>

-- 
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

Re: [VOTE] Update the committer guidelines to clarify when to commit changes.

[Jungtaek Lim]

+1 (non-binding, I guess)

Thanks for raising the issue and sorting it out!

On Fri, Jul 31, 2020 at 6:47 AM Holden Karau  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  
> YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>

[VOTE] Update the committer guidelines to clarify when to commit changes.

[Holden Karau]

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  
YouTube Live Streams: https://www.youtube.com/user/holdenkarau