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

[Prashant Sharma <sc...@gmail.com>]

+1

On Fri, Jul 31, 2020 at 10:18 PM Xiao Li <li...@databricks.com> wrote:

> +1
>
> Xiao
>
> On Fri, Jul 31, 2020 at 9:32 AM Mridul Muralidharan <mr...@gmail.com>
> wrote:
>
>>
>> +1
>>
>> Thanks,
>> Mridul
>>
>> On Thu, Jul 30, 2020 at 4:49 PM Holden Karau <ho...@pigscanfly.ca>
>> 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  <https://amzn.to/2MaRAG9>
>>> YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>>>
>>
>
> --
> <https://databricks.com/sparkaisummit/north-america>
>

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

[Holden Karau <ho...@pigscanfly.ca>]

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 <sc...@gmail.com> wrote:

> +1
>
> On Fri, Jul 31, 2020 at 10:18 PM Xiao Li <li...@databricks.com> wrote:
>
>> +1
>>
>> Xiao
>>
>> On Fri, Jul 31, 2020 at 9:32 AM Mridul Muralidharan <mr...@gmail.com>
>> wrote:
>>
>>>
>>> +1
>>>
>>> Thanks,
>>> Mridul
>>>
>>> On Thu, Jul 30, 2020 at 4:49 PM Holden Karau <ho...@pigscanfly.ca>
>>> 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  <https://amzn.to/2MaRAG9>
>>>> YouTube Live Streams: https://www.youtube.com/user/holdenkarau
>>>>
>>>
>>
>> --
>> <https://databricks.com/sparkaisummit/north-america>
>>
> --
Twitter: https://twitter.com/holdenkarau
Books (Learning Spark, High Performance Spark, etc.):
https://amzn.to/2MaRAG9  <https://amzn.to/2MaRAG9>
YouTube Live Streams: https://www.youtube.com/user/holdenkarau