[DISCUSS] Amend the commiter guidelines on the subject of -1s & how we expect PR discussion to be treated.

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

[DISCUSS] Amend the commiter guidelines on the subject of -1s & how we expect PR discussion to be treated.

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

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

Re: [DISCUSS] Amend the commiter guidelines on the subject of -1s & how we expect PR discussion to be treated.

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

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

Re: [DISCUSS] Amend the commiter guidelines on the subject of -1s & how we expect PR discussion to be treated.

Holden Karau


On Wed, Jul 22, 2020 at 7:39 AM Imran Rashid < [hidden email] > wrote:
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".
I can work with that although it wasn’t quite what I was originally going for. I didn’t intend to have committer -1s be eligible for override. I believe committers have demonstrated sufficient merit; they are the same as PMC member -1s in our project.

My aim was just if something weird happens (like say I had a pending -1 before my motorcycle crash last year) we go to the PMC and take a binding vote on what to do, and most likely someone on the PMC will reach out to the ASF for understanding around the guidelines.

What about:

All -1s with justification merit discussion.  A -1 from a non-committer can be overridden only with input from multiple committers and suitable time for any committer to raise concerns.  A -1 from a committer who can not be reached requires a consensus vote of the PMC under ASF voting rules to determine the next steps within the ASF guidelines for vetos.


thanks,
Imran


On Tue, Jul 21, 2020 at 3:41 PM Holden Karau <[hidden email]> 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

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

Re: [DISCUSS] Amend the commiter guidelines on the subject of -1s & how we expect PR discussion to be treated.

Imran Rashid-5
Sure, that sounds good to me.  +1

On Wed, Jul 22, 2020 at 1:50 PM Holden Karau <[hidden email]> wrote:


On Wed, Jul 22, 2020 at 7:39 AM Imran Rashid < [hidden email] > wrote:
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".
I can work with that although it wasn’t quite what I was originally going for. I didn’t intend to have committer -1s be eligible for override. I believe committers have demonstrated sufficient merit; they are the same as PMC member -1s in our project.

My aim was just if something weird happens (like say I had a pending -1 before my motorcycle crash last year) we go to the PMC and take a binding vote on what to do, and most likely someone on the PMC will reach out to the ASF for understanding around the guidelines.

What about:

All -1s with justification merit discussion.  A -1 from a non-committer can be overridden only with input from multiple committers and suitable time for any committer to raise concerns.  A -1 from a committer who can not be reached requires a consensus vote of the PMC under ASF voting rules to determine the next steps within the ASF guidelines for vetos.


thanks,
Imran


On Tue, Jul 21, 2020 at 3:41 PM Holden Karau <[hidden email]> 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

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

Re: [DISCUSS] Amend the commiter guidelines on the subject of -1s & how we expect PR discussion to be treated.

Mridul Muralidharan

Thanks Holden, this version looks good to me.
+1

Regards,
Mridul


On Thu, Jul 23, 2020 at 3:56 PM Imran Rashid <[hidden email]> wrote:
Sure, that sounds good to me.  +1

On Wed, Jul 22, 2020 at 1:50 PM Holden Karau <[hidden email]> wrote:


On Wed, Jul 22, 2020 at 7:39 AM Imran Rashid < [hidden email] > wrote:
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".
I can work with that although it wasn’t quite what I was originally going for. I didn’t intend to have committer -1s be eligible for override. I believe committers have demonstrated sufficient merit; they are the same as PMC member -1s in our project.

My aim was just if something weird happens (like say I had a pending -1 before my motorcycle crash last year) we go to the PMC and take a binding vote on what to do, and most likely someone on the PMC will reach out to the ASF for understanding around the guidelines.

What about:

All -1s with justification merit discussion.  A -1 from a non-committer can be overridden only with input from multiple committers and suitable time for any committer to raise concerns.  A -1 from a committer who can not be reached requires a consensus vote of the PMC under ASF voting rules to determine the next steps within the ASF guidelines for vetos.


thanks,
Imran


On Tue, Jul 21, 2020 at 3:41 PM Holden Karau <[hidden email]> 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

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

Re: [DISCUSS] Amend the commiter guidelines on the subject of -1s & how we expect PR discussion to be treated.

Tom Graves-2
In reply to this post by Holden Karau
+1

Tom

On Tuesday, July 21, 2020, 03:35:18 PM CDT, Holden Karau <[hidden email]> 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

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

Re: [DISCUSS] Amend the commiter guidelines on the subject of -1s & how we expect PR discussion to be treated.

Hyukjin Kwon
+1 thanks Holden.

On Fri, 24 Jul 2020, 22:34 Tom Graves, <[hidden email]> wrote:
+1

Tom

On Tuesday, July 21, 2020, 03:35:18 PM CDT, Holden Karau <[hidden email]> 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

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

Re: [DISCUSS] Amend the commiter guidelines on the subject of -1s & how we expect PR discussion to be treated.

Holden Karau
It sounds like with the slight wording change we’re in agreement so I’ll bounce this by an editor friend to fix my grammar/spelling before I put it up for a vote.

On Sat, Jul 25, 2020 at 9:23 PM Hyukjin Kwon <[hidden email]> wrote:
+1 thanks Holden.

On Fri, 24 Jul 2020, 22:34 Tom Graves, <[hidden email]> wrote:
+1

Tom

On Tuesday, July 21, 2020, 03:35:18 PM CDT, Holden Karau <[hidden email]> 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

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