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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[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

--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 
Reply | Threaded
Open this post in threaded view
|

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

Jungtaek Lim-2
+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 <[hidden email]> 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

--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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

--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 


--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 
Reply | Threaded
Open this post in threaded view
|

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

cloud0fan
+1, thanks for driving it, Holden!

On Fri, Jul 31, 2020 at 10:24 AM Holden Karau <[hidden email]> wrote:
+1 from myself :)

On Thu, Jul 30, 2020 at 2:53 PM Jungtaek Lim <[hidden email]> 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 <[hidden email]> 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

--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 


--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:

>
> +1, thanks for driving it, Holden!
>
> On Fri, Jul 31, 2020 at 10:24 AM Holden Karau <[hidden email]> wrote:
>>
>> +1 from myself :)
>>
>> On Thu, Jul 30, 2020 at 2:53 PM Jungtaek Lim <[hidden email]> 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 <[hidden email]> 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: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Mridul Muralidharan
In reply to this post by Holden Karau

+1

Thanks,
Mridul 

On Thu, Jul 30, 2020 at 4:49 PM Holden Karau <[hidden email]> 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


--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 
Reply | Threaded
Open this post in threaded view
|

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

Xiao Li-2
+1 

Xiao

On Fri, Jul 31, 2020 at 9:32 AM Mridul Muralidharan <[hidden email]> wrote:

+1

Thanks,
Mridul 

On Thu, Jul 30, 2020 at 4:49 PM Holden Karau <[hidden email]> 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


--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 


--
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
+1 

Xiao

On Fri, Jul 31, 2020 at 9:32 AM Mridul Muralidharan <[hidden email]> wrote:

+1

Thanks,
Mridul 

On Thu, Jul 30, 2020 at 4:49 PM Holden Karau <[hidden email]> 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


--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 


--
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
+1

On Fri, Jul 31, 2020 at 10:18 PM Xiao Li <[hidden email]> wrote:
+1 

Xiao

On Fri, Jul 31, 2020 at 9:32 AM Mridul Muralidharan <[hidden email]> wrote:

+1

Thanks,
Mridul 

On Thu, Jul 30, 2020 at 4:49 PM Holden Karau <[hidden email]> 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


--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9 


--
--
Books (Learning Spark, High Performance Spark, etc.): https://amzn.to/2MaRAG9