Re: [VOTE] Project governance wiki doc (take 2)

2020-06-25 Thread Joshua McKenzie
Probably worth linking to the apache CoC in our wiki if we haven't already.

On Thu, Jun 25, 2020 at 2:31 PM Dinesh Joshi  wrote:

> > On Jun 25, 2020, at 8:28 AM, Joshua McKenzie 
> wrote:
> >
> > Dinesh - I expect to see a [DISCUSS] thread from you about our CoC
> shortly.
> > :)
> >
>
> I am satisfied with Benedict's clarification. ASF CoC and processes
> outlined in there are fine.
>
> Dinesh
>
>
>
> > ~Josh
> >
> > On Thu, Jun 25, 2020 at 4:17 AM Aaron Morton 
> > wrote:
> >
> >> +1
> >>
> >> -
> >> Aaron Morton
> >> New Zealand
> >> @aaronmorton
> >>
> >> CEO
> >> Apache Cassandra Consulting
> >> http://www.thelastpickle.com
> >>
> >>
> >> On Thu, 25 Jun 2020 at 19:46, Benedict Elliott Smith <
> bened...@apache.org>
> >> wrote:
> >>
> >>> The purpose of this document is to define only how the project makes
> >>> decisions, and it lists "tenets" of conduct only as a preamble for
> >>> interpreting the rules on decision-making.  The authors' intent was to
> >> lean
> >>> on this to minimise the rigidity and prescriptiveness in the
> formulation
> >> of
> >>> the rules (so that we could e.g. use "reasonable" repeatedly, instead
> of
> >>> specifying precise expectations), in part because this is our first
> >> attempt
> >>> to codify such rules, and in part because rigidity can cause
> unnecessary
> >>> friction to a project that mostly runs smoothly.
> >>>
> >>> The document provides an avenue for resolving disputes in
> decision-making
> >>> when these assumptions on behaviour breakdown. However its scope
> >> definitely
> >>> isn't, at least in my opinion, addressing misbehaviour by individuals
> >> (i.e.
> >>> one of the serious breaches listed in part 5 of the Apache CoC), which
> it
> >>> seems to me you are addressing here?
> >>>
> >>> Since we reference the ASF CoC, and the ASF provides its own guide for
> >>> handling CoC complaints (including within projects), that applies to
> that
> >>> very CoC (and which you referenced), it's unclear to me what you're
> >> looking
> >>> for.  Are you looking for a more project-specific CoC with different
> >>> guidelines for reporting?  This is something you would be welcome to
> >>> undertake, and seek consensus for.
> >>>
> >>>
> >>>
> >>>
> >>> On 25/06/2020, 02:38, "Dinesh Joshi"  wrote:
> >>>
>  On Jun 24, 2020, at 6:01 PM, Brandon Williams 
> >>> wrote:
> 
>  On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi 
> >>> wrote:
> > 1. How/Who/Where are we planning to deal with Code of Conduct
> >>> violations? I assume this should be private@ but the document does not
> >>> call it out as such. We should call it out explicitly as part of the
> PMC
> >>> responsibilities. We should also clarify how and where are CoC
> violations
> >>> against PMC members reported and handled? Should they go to ASF?
> 
>  I think if we assume good intent, this will be a non-issue.  People
>  may make mistakes, but I try to have faith they will realize them
> >> and
>  act accordingly when told so without any need to escalate.
> >>>
> >>>We need to spell out in the document how and where the CoC
> violations
> >>> are reported irrespective of the role of the person in the community.
> >> This
> >>> is a critical point to address. ASF spells this out very clearly[1]. We
> >>> should have a similar statement in the Project Governance document,
> >>> otherwise it feels incomplete to me.
> >>>
> >>>Dinesh
> >>>
> >>>[1]
> >>>
> >>
> http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
> >>>
> -
> >>>To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-25 Thread Dinesh Joshi
> On Jun 25, 2020, at 8:28 AM, Joshua McKenzie  wrote:
> 
> Dinesh - I expect to see a [DISCUSS] thread from you about our CoC shortly.
> :)
> 

I am satisfied with Benedict's clarification. ASF CoC and processes outlined in 
there are fine.

Dinesh



> ~Josh
> 
> On Thu, Jun 25, 2020 at 4:17 AM Aaron Morton 
> wrote:
> 
>> +1
>> 
>> -
>> Aaron Morton
>> New Zealand
>> @aaronmorton
>> 
>> CEO
>> Apache Cassandra Consulting
>> http://www.thelastpickle.com
>> 
>> 
>> On Thu, 25 Jun 2020 at 19:46, Benedict Elliott Smith 
>> wrote:
>> 
>>> The purpose of this document is to define only how the project makes
>>> decisions, and it lists "tenets" of conduct only as a preamble for
>>> interpreting the rules on decision-making.  The authors' intent was to
>> lean
>>> on this to minimise the rigidity and prescriptiveness in the formulation
>> of
>>> the rules (so that we could e.g. use "reasonable" repeatedly, instead of
>>> specifying precise expectations), in part because this is our first
>> attempt
>>> to codify such rules, and in part because rigidity can cause unnecessary
>>> friction to a project that mostly runs smoothly.
>>> 
>>> The document provides an avenue for resolving disputes in decision-making
>>> when these assumptions on behaviour breakdown. However its scope
>> definitely
>>> isn't, at least in my opinion, addressing misbehaviour by individuals
>> (i.e.
>>> one of the serious breaches listed in part 5 of the Apache CoC), which it
>>> seems to me you are addressing here?
>>> 
>>> Since we reference the ASF CoC, and the ASF provides its own guide for
>>> handling CoC complaints (including within projects), that applies to that
>>> very CoC (and which you referenced), it's unclear to me what you're
>> looking
>>> for.  Are you looking for a more project-specific CoC with different
>>> guidelines for reporting?  This is something you would be welcome to
>>> undertake, and seek consensus for.
>>> 
>>> 
>>> 
>>> 
>>> On 25/06/2020, 02:38, "Dinesh Joshi"  wrote:
>>> 
 On Jun 24, 2020, at 6:01 PM, Brandon Williams 
>>> wrote:
 
 On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi 
>>> wrote:
> 1. How/Who/Where are we planning to deal with Code of Conduct
>>> violations? I assume this should be private@ but the document does not
>>> call it out as such. We should call it out explicitly as part of the PMC
>>> responsibilities. We should also clarify how and where are CoC violations
>>> against PMC members reported and handled? Should they go to ASF?
 
 I think if we assume good intent, this will be a non-issue.  People
 may make mistakes, but I try to have faith they will realize them
>> and
 act accordingly when told so without any need to escalate.
>>> 
>>>We need to spell out in the document how and where the CoC violations
>>> are reported irrespective of the role of the person in the community.
>> This
>>> is a critical point to address. ASF spells this out very clearly[1]. We
>>> should have a similar statement in the Project Governance document,
>>> otherwise it feels incomplete to me.
>>> 
>>>Dinesh
>>> 
>>>[1]
>>> 
>> http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
>>>-
>>>To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>>For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-25 Thread Joshua McKenzie
Vote results:
Binding +1's: 17
Binding +0's: 1
Binding -1's: 0

Non-binding +1's: 9
Non-binding +0's: 1
Non-binding -1's: 0

The vote passes.

pmc quorum for the next six months (or whatever cadence we decide to roll
call on) will be 18, with low watermark of simple majority to pass pmc
votes defined as 10.

Thanks everyone for the great discussion on the topic and all the
collaboration. I'll update the wiki to reflect the state of governance on
the project.

Dinesh - I expect to see a [DISCUSS] thread from you about our CoC shortly.
:)

~Josh

On Thu, Jun 25, 2020 at 4:17 AM Aaron Morton 
wrote:

> +1
>
> -
> Aaron Morton
> New Zealand
> @aaronmorton
>
> CEO
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>
>
> On Thu, 25 Jun 2020 at 19:46, Benedict Elliott Smith 
> wrote:
>
> > The purpose of this document is to define only how the project makes
> > decisions, and it lists "tenets" of conduct only as a preamble for
> > interpreting the rules on decision-making.  The authors' intent was to
> lean
> > on this to minimise the rigidity and prescriptiveness in the formulation
> of
> > the rules (so that we could e.g. use "reasonable" repeatedly, instead of
> > specifying precise expectations), in part because this is our first
> attempt
> > to codify such rules, and in part because rigidity can cause unnecessary
> > friction to a project that mostly runs smoothly.
> >
> > The document provides an avenue for resolving disputes in decision-making
> > when these assumptions on behaviour breakdown. However its scope
> definitely
> > isn't, at least in my opinion, addressing misbehaviour by individuals
> (i.e.
> > one of the serious breaches listed in part 5 of the Apache CoC), which it
> > seems to me you are addressing here?
> >
> > Since we reference the ASF CoC, and the ASF provides its own guide for
> > handling CoC complaints (including within projects), that applies to that
> > very CoC (and which you referenced), it's unclear to me what you're
> looking
> > for.  Are you looking for a more project-specific CoC with different
> > guidelines for reporting?  This is something you would be welcome to
> > undertake, and seek consensus for.
> >
> >
> >
> >
> > On 25/06/2020, 02:38, "Dinesh Joshi"  wrote:
> >
> > > On Jun 24, 2020, at 6:01 PM, Brandon Williams 
> > wrote:
> > >
> > > On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi 
> > wrote:
> > >> 1. How/Who/Where are we planning to deal with Code of Conduct
> > violations? I assume this should be private@ but the document does not
> > call it out as such. We should call it out explicitly as part of the PMC
> > responsibilities. We should also clarify how and where are CoC violations
> > against PMC members reported and handled? Should they go to ASF?
> > >
> > > I think if we assume good intent, this will be a non-issue.  People
> > > may make mistakes, but I try to have faith they will realize them
> and
> > > act accordingly when told so without any need to escalate.
> >
> > We need to spell out in the document how and where the CoC violations
> > are reported irrespective of the role of the person in the community.
> This
> > is a critical point to address. ASF spells this out very clearly[1]. We
> > should have a similar statement in the Project Governance document,
> > otherwise it feels incomplete to me.
> >
> > Dinesh
> >
> > [1]
> >
> http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-25 Thread Benedict Elliott Smith
The purpose of this document is to define only how the project makes decisions, 
and it lists "tenets" of conduct only as a preamble for interpreting the rules 
on decision-making.  The authors' intent was to lean on this to minimise the 
rigidity and prescriptiveness in the formulation of the rules (so that we could 
e.g. use "reasonable" repeatedly, instead of specifying precise expectations), 
in part because this is our first attempt to codify such rules, and in part 
because rigidity can cause unnecessary friction to a project that mostly runs 
smoothly.  

The document provides an avenue for resolving disputes in decision-making when 
these assumptions on behaviour breakdown. However its scope definitely isn't, 
at least in my opinion, addressing misbehaviour by individuals (i.e. one of the 
serious breaches listed in part 5 of the Apache CoC), which it seems to me you 
are addressing here?

Since we reference the ASF CoC, and the ASF provides its own guide for handling 
CoC complaints (including within projects), that applies to that very CoC (and 
which you referenced), it's unclear to me what you're looking for.  Are you 
looking for a more project-specific CoC with different guidelines for 
reporting?  This is something you would be welcome to undertake, and seek 
consensus for.




On 25/06/2020, 02:38, "Dinesh Joshi"  wrote:

> On Jun 24, 2020, at 6:01 PM, Brandon Williams  wrote:
> 
> On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi  wrote:
>> 1. How/Who/Where are we planning to deal with Code of Conduct 
violations? I assume this should be private@ but the document does not call it 
out as such. We should call it out explicitly as part of the PMC 
responsibilities. We should also clarify how and where are CoC violations 
against PMC members reported and handled? Should they go to ASF?
> 
> I think if we assume good intent, this will be a non-issue.  People
> may make mistakes, but I try to have faith they will realize them and
> act accordingly when told so without any need to escalate.

We need to spell out in the document how and where the CoC violations are 
reported irrespective of the role of the person in the community. This is a 
critical point to address. ASF spells this out very clearly[1]. We should have 
a similar statement in the Project Governance document, otherwise it feels 
incomplete to me.

Dinesh

[1] 
http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-24 Thread Dinesh Joshi
> On Jun 24, 2020, at 6:01 PM, Brandon Williams  wrote:
> 
> On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi  wrote:
>> 1. How/Who/Where are we planning to deal with Code of Conduct violations? I 
>> assume this should be private@ but the document does not call it out as 
>> such. We should call it out explicitly as part of the PMC responsibilities. 
>> We should also clarify how and where are CoC violations against PMC members 
>> reported and handled? Should they go to ASF?
> 
> I think if we assume good intent, this will be a non-issue.  People
> may make mistakes, but I try to have faith they will realize them and
> act accordingly when told so without any need to escalate.

We need to spell out in the document how and where the CoC violations are 
reported irrespective of the role of the person in the community. This is a 
critical point to address. ASF spells this out very clearly[1]. We should have 
a similar statement in the Project Governance document, otherwise it feels 
incomplete to me.

Dinesh

[1] http://www.apache.org/foundation/policies/conduct.html#reporting-guidelines
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-24 Thread Jeremy Hanna



> On Jun 25, 2020, at 10:56 AM, Jordan West  wrote:
> 
> On Wed, Jun 24, 2020 at 3:43 PM Dinesh Joshi  wrote:
> 
>> 3. Discussion #3 - "... 1 business day notice period."  Whose business day
>> is it? US? Europe? Australia? NZ? We are a distributed community and so 1
>> business day is ambiguous. ASF typically states a 48-72 hour period which
>> gives enough time to cover everyone in the community. We want to avoid
>> people getting disenfranchised due to their location. I propose we make
>> this longer and avoid using 'business day' language.
>> 
>> 
> I'll take responsibility for that. It was one of the discussions on the
> google doc during the initial round of feedback.  The intention was to
> ensure folks didn't feel obligated to check the mailing list on the
> weekends or holidays (regardless of location) since we are all volunteering
> our time. I intended it to mean "not on weekends or holidays for you". We
> can use more specific language if we feel its necessary.
> 

I do agree with the intent of not being burdensome for a community of 
volunteers with lives beyond the project.  However I think 48 or 72 hours is 
probably better and left unqualified because it's tricky.  Besides holidays 
which vary wildly, the weekend starts on the US Friday in the Asia Pacific 
region.  Also Friday/Saturday is the weekend in Israel.

> 
>> Thanks,
>> 
>> Dinesh
>> 
>> [1] https://www.apache.org/foundation/voting.html#Veto
>> 
>>> On Jun 24, 2020, at 2:59 PM, sankalp kohli 
>> wrote:
>>> 
>>> +1
>>> 
>>> On Wed, Jun 24, 2020 at 8:37 AM Jake Luciani  wrote:
>>> 
 +1 (b)
 
 On Wed, Jun 24, 2020 at 9:59 AM Joshua McKenzie 
 wrote:
 
> A reminder: this vote will close at midnight PST today in roughly 17
 hours.
> 
> 
> On Mon, Jun 22, 2020 at 2:20 PM J. D. Jordan <
>> jeremiah.jor...@gmail.com>
> wrote:
> 
>> +1 non-binding
>> 
>>> On Jun 22, 2020, at 1:18 PM, Stefan Podkowinski 
> wrote:
>>> 
>>> +1
>>> 
 On 22.06.20 20:12, Blake Eggleston wrote:
 +1
 
>> On Jun 20, 2020, at 8:12 AM, Joshua McKenzie <
 jmcken...@apache.org>
>> wrote:
> 
> Link to doc:
> 
>> 
> 
 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> 
> Change since previous cancelled vote:
> "A simple majority of this electorate becomes the low-watermark for
>> votes
> in favour necessary to pass a motion, with new PMC members added to
> the
> calculation."
> 
> This previously read "super majority". We have lowered the low
 water
>> mark
> to "simple majority" to balance strong consensus against risk of
> stall
>> due
> to low participation.
> 
> 
> - Vote will run through 6/24/20
> - pmc votes considered binding
> - simple majority of binding participants passes the vote
> - committer and community votes considered advisory
> 
> Lastly, I propose we take the count of pmc votes in this thread as
> our
> initial roll call count for electorate numbers and low watermark
> calculation on subsequent votes.
> 
> Thanks again everyone (and specifically Benedict and Jon) for the
> time
>> and
> collaboration on this.
> 
> ~Josh
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
> 
 
 
 --
 http://twitter.com/tjake
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-24 Thread Brandon Williams
On Wed, Jun 24, 2020 at 5:43 PM Dinesh Joshi  wrote:
> 1. How/Who/Where are we planning to deal with Code of Conduct violations? I 
> assume this should be private@ but the document does not call it out as such. 
> We should call it out explicitly as part of the PMC responsibilities. We 
> should also clarify how and where are CoC violations against PMC members 
> reported and handled? Should they go to ASF?

I think if we assume good intent, this will be a non-issue.  People
may make mistakes, but I try to have faith they will realize them and
act accordingly when told so without any need to escalate.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-24 Thread Jordan West
On Wed, Jun 24, 2020 at 3:43 PM Dinesh Joshi  wrote:

> 3. Discussion #3 - "... 1 business day notice period."  Whose business day
> is it? US? Europe? Australia? NZ? We are a distributed community and so 1
> business day is ambiguous. ASF typically states a 48-72 hour period which
> gives enough time to cover everyone in the community. We want to avoid
> people getting disenfranchised due to their location. I propose we make
> this longer and avoid using 'business day' language.
>
>
I'll take responsibility for that. It was one of the discussions on the
google doc during the initial round of feedback.  The intention was to
ensure folks didn't feel obligated to check the mailing list on the
weekends or holidays (regardless of location) since we are all volunteering
our time. I intended it to mean "not on weekends or holidays for you". We
can use more specific language if we feel its necessary.


> Thanks,
>
> Dinesh
>
> [1] https://www.apache.org/foundation/voting.html#Veto
>
> > On Jun 24, 2020, at 2:59 PM, sankalp kohli 
> wrote:
> >
> > +1
> >
> > On Wed, Jun 24, 2020 at 8:37 AM Jake Luciani  wrote:
> >
> >> +1 (b)
> >>
> >> On Wed, Jun 24, 2020 at 9:59 AM Joshua McKenzie 
> >> wrote:
> >>
> >>> A reminder: this vote will close at midnight PST today in roughly 17
> >> hours.
> >>>
> >>>
> >>> On Mon, Jun 22, 2020 at 2:20 PM J. D. Jordan <
> jeremiah.jor...@gmail.com>
> >>> wrote:
> >>>
>  +1 non-binding
> 
> > On Jun 22, 2020, at 1:18 PM, Stefan Podkowinski 
> >>> wrote:
> >
> > +1
> >
> >> On 22.06.20 20:12, Blake Eggleston wrote:
> >> +1
> >>
>  On Jun 20, 2020, at 8:12 AM, Joshua McKenzie <
> >> jmcken...@apache.org>
>  wrote:
> >>>
> >>> Link to doc:
> >>>
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >>>
> >>> Change since previous cancelled vote:
> >>> "A simple majority of this electorate becomes the low-watermark for
>  votes
> >>> in favour necessary to pass a motion, with new PMC members added to
> >>> the
> >>> calculation."
> >>>
> >>> This previously read "super majority". We have lowered the low
> >> water
>  mark
> >>> to "simple majority" to balance strong consensus against risk of
> >>> stall
>  due
> >>> to low participation.
> >>>
> >>>
> >>>  - Vote will run through 6/24/20
> >>>  - pmc votes considered binding
> >>>  - simple majority of binding participants passes the vote
> >>>  - committer and community votes considered advisory
> >>>
> >>> Lastly, I propose we take the count of pmc votes in this thread as
> >>> our
> >>> initial roll call count for electorate numbers and low watermark
> >>> calculation on subsequent votes.
> >>>
> >>> Thanks again everyone (and specifically Benedict and Jon) for the
> >>> time
>  and
> >>> collaboration on this.
> >>>
> >>> ~Josh
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> >>>
> >>
> >>
> >> --
> >> http://twitter.com/tjake
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-24 Thread Dinesh Joshi
+0

I realize this is a vote thread and I am late for feedback but I wanted to 
point out a couple things:

1. How/Who/Where are we planning to deal with Code of Conduct violations? I 
assume this should be private@ but the document does not call it out as such. 
We should call it out explicitly as part of the PMC responsibilities. We should 
also clarify how and where are CoC violations against PMC members reported and 
handled? Should they go to ASF?

2. Regarding vetos, I see we're aligning on ASF principles. Using -1s in a 
discussion or debate is very unproductive therefore we should explicitly call 
out that vetos (or threat of a veto) should not be used in any discussion. It 
should only be issued per the ASF guidelines[1].

3. Discussion #3 - "... 1 business day notice period."  Whose business day is 
it? US? Europe? Australia? NZ? We are a distributed community and so 1 business 
day is ambiguous. ASF typically states a 48-72 hour period which gives enough 
time to cover everyone in the community. We want to avoid people getting 
disenfranchised due to their location. I propose we make this longer and avoid 
using 'business day' language.

Thanks,

Dinesh

[1] https://www.apache.org/foundation/voting.html#Veto

> On Jun 24, 2020, at 2:59 PM, sankalp kohli  wrote:
> 
> +1
> 
> On Wed, Jun 24, 2020 at 8:37 AM Jake Luciani  wrote:
> 
>> +1 (b)
>> 
>> On Wed, Jun 24, 2020 at 9:59 AM Joshua McKenzie 
>> wrote:
>> 
>>> A reminder: this vote will close at midnight PST today in roughly 17
>> hours.
>>> 
>>> 
>>> On Mon, Jun 22, 2020 at 2:20 PM J. D. Jordan 
>>> wrote:
>>> 
 +1 non-binding
 
> On Jun 22, 2020, at 1:18 PM, Stefan Podkowinski 
>>> wrote:
> 
> +1
> 
>> On 22.06.20 20:12, Blake Eggleston wrote:
>> +1
>> 
 On Jun 20, 2020, at 8:12 AM, Joshua McKenzie <
>> jmcken...@apache.org>
 wrote:
>>> 
>>> Link to doc:
>>> 
 
>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>>> 
>>> Change since previous cancelled vote:
>>> "A simple majority of this electorate becomes the low-watermark for
 votes
>>> in favour necessary to pass a motion, with new PMC members added to
>>> the
>>> calculation."
>>> 
>>> This previously read "super majority". We have lowered the low
>> water
 mark
>>> to "simple majority" to balance strong consensus against risk of
>>> stall
 due
>>> to low participation.
>>> 
>>> 
>>>  - Vote will run through 6/24/20
>>>  - pmc votes considered binding
>>>  - simple majority of binding participants passes the vote
>>>  - committer and community votes considered advisory
>>> 
>>> Lastly, I propose we take the count of pmc votes in this thread as
>>> our
>>> initial roll call count for electorate numbers and low watermark
>>> calculation on subsequent votes.
>>> 
>>> Thanks again everyone (and specifically Benedict and Jon) for the
>>> time
 and
>>> collaboration on this.
>>> 
>>> ~Josh
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>>> 
>> 
>> 
>> --
>> http://twitter.com/tjake
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-24 Thread sankalp kohli
+1

On Wed, Jun 24, 2020 at 8:37 AM Jake Luciani  wrote:

> +1 (b)
>
> On Wed, Jun 24, 2020 at 9:59 AM Joshua McKenzie 
> wrote:
>
> > A reminder: this vote will close at midnight PST today in roughly 17
> hours.
> >
> >
> > On Mon, Jun 22, 2020 at 2:20 PM J. D. Jordan 
> > wrote:
> >
> > > +1 non-binding
> > >
> > > > On Jun 22, 2020, at 1:18 PM, Stefan Podkowinski 
> > wrote:
> > > >
> > > > +1
> > > >
> > > >> On 22.06.20 20:12, Blake Eggleston wrote:
> > > >> +1
> > > >>
> > >  On Jun 20, 2020, at 8:12 AM, Joshua McKenzie <
> jmcken...@apache.org>
> > > wrote:
> > > >>>
> > > >>> Link to doc:
> > > >>>
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > >>>
> > > >>> Change since previous cancelled vote:
> > > >>> "A simple majority of this electorate becomes the low-watermark for
> > > votes
> > > >>> in favour necessary to pass a motion, with new PMC members added to
> > the
> > > >>> calculation."
> > > >>>
> > > >>> This previously read "super majority". We have lowered the low
> water
> > > mark
> > > >>> to "simple majority" to balance strong consensus against risk of
> > stall
> > > due
> > > >>> to low participation.
> > > >>>
> > > >>>
> > > >>>   - Vote will run through 6/24/20
> > > >>>   - pmc votes considered binding
> > > >>>   - simple majority of binding participants passes the vote
> > > >>>   - committer and community votes considered advisory
> > > >>>
> > > >>> Lastly, I propose we take the count of pmc votes in this thread as
> > our
> > > >>> initial roll call count for electorate numbers and low watermark
> > > >>> calculation on subsequent votes.
> > > >>>
> > > >>> Thanks again everyone (and specifically Benedict and Jon) for the
> > time
> > > and
> > > >>> collaboration on this.
> > > >>>
> > > >>> ~Josh
> > > >>
> > > >>
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >>
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>
>
> --
> http://twitter.com/tjake
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-24 Thread Jake Luciani
+1 (b)

On Wed, Jun 24, 2020 at 9:59 AM Joshua McKenzie 
wrote:

> A reminder: this vote will close at midnight PST today in roughly 17 hours.
>
>
> On Mon, Jun 22, 2020 at 2:20 PM J. D. Jordan 
> wrote:
>
> > +1 non-binding
> >
> > > On Jun 22, 2020, at 1:18 PM, Stefan Podkowinski 
> wrote:
> > >
> > > +1
> > >
> > >> On 22.06.20 20:12, Blake Eggleston wrote:
> > >> +1
> > >>
> >  On Jun 20, 2020, at 8:12 AM, Joshua McKenzie 
> > wrote:
> > >>>
> > >>> Link to doc:
> > >>>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > >>>
> > >>> Change since previous cancelled vote:
> > >>> "A simple majority of this electorate becomes the low-watermark for
> > votes
> > >>> in favour necessary to pass a motion, with new PMC members added to
> the
> > >>> calculation."
> > >>>
> > >>> This previously read "super majority". We have lowered the low water
> > mark
> > >>> to "simple majority" to balance strong consensus against risk of
> stall
> > due
> > >>> to low participation.
> > >>>
> > >>>
> > >>>   - Vote will run through 6/24/20
> > >>>   - pmc votes considered binding
> > >>>   - simple majority of binding participants passes the vote
> > >>>   - committer and community votes considered advisory
> > >>>
> > >>> Lastly, I propose we take the count of pmc votes in this thread as
> our
> > >>> initial roll call count for electorate numbers and low watermark
> > >>> calculation on subsequent votes.
> > >>>
> > >>> Thanks again everyone (and specifically Benedict and Jon) for the
> time
> > and
> > >>> collaboration on this.
> > >>>
> > >>> ~Josh
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>


-- 
http://twitter.com/tjake


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-24 Thread Joshua McKenzie
A reminder: this vote will close at midnight PST today in roughly 17 hours.


On Mon, Jun 22, 2020 at 2:20 PM J. D. Jordan 
wrote:

> +1 non-binding
>
> > On Jun 22, 2020, at 1:18 PM, Stefan Podkowinski  wrote:
> >
> > +1
> >
> >> On 22.06.20 20:12, Blake Eggleston wrote:
> >> +1
> >>
>  On Jun 20, 2020, at 8:12 AM, Joshua McKenzie 
> wrote:
> >>>
> >>> Link to doc:
> >>>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >>>
> >>> Change since previous cancelled vote:
> >>> "A simple majority of this electorate becomes the low-watermark for
> votes
> >>> in favour necessary to pass a motion, with new PMC members added to the
> >>> calculation."
> >>>
> >>> This previously read "super majority". We have lowered the low water
> mark
> >>> to "simple majority" to balance strong consensus against risk of stall
> due
> >>> to low participation.
> >>>
> >>>
> >>>   - Vote will run through 6/24/20
> >>>   - pmc votes considered binding
> >>>   - simple majority of binding participants passes the vote
> >>>   - committer and community votes considered advisory
> >>>
> >>> Lastly, I propose we take the count of pmc votes in this thread as our
> >>> initial roll call count for electorate numbers and low watermark
> >>> calculation on subsequent votes.
> >>>
> >>> Thanks again everyone (and specifically Benedict and Jon) for the time
> and
> >>> collaboration on this.
> >>>
> >>> ~Josh
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread J. D. Jordan
+1 non-binding

> On Jun 22, 2020, at 1:18 PM, Stefan Podkowinski  wrote:
> 
> +1
> 
>> On 22.06.20 20:12, Blake Eggleston wrote:
>> +1
>> 
 On Jun 20, 2020, at 8:12 AM, Joshua McKenzie  wrote:
>>> 
>>> Link to doc:
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>>> 
>>> Change since previous cancelled vote:
>>> "A simple majority of this electorate becomes the low-watermark for votes
>>> in favour necessary to pass a motion, with new PMC members added to the
>>> calculation."
>>> 
>>> This previously read "super majority". We have lowered the low water mark
>>> to "simple majority" to balance strong consensus against risk of stall due
>>> to low participation.
>>> 
>>> 
>>>   - Vote will run through 6/24/20
>>>   - pmc votes considered binding
>>>   - simple majority of binding participants passes the vote
>>>   - committer and community votes considered advisory
>>> 
>>> Lastly, I propose we take the count of pmc votes in this thread as our
>>> initial roll call count for electorate numbers and low watermark
>>> calculation on subsequent votes.
>>> 
>>> Thanks again everyone (and specifically Benedict and Jon) for the time and
>>> collaboration on this.
>>> 
>>> ~Josh
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Stefan Podkowinski

+1

On 22.06.20 20:12, Blake Eggleston wrote:

+1


On Jun 20, 2020, at 8:12 AM, Joshua McKenzie  wrote:

Link to doc:
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance

Change since previous cancelled vote:
"A simple majority of this electorate becomes the low-watermark for votes
in favour necessary to pass a motion, with new PMC members added to the
calculation."

This previously read "super majority". We have lowered the low water mark
to "simple majority" to balance strong consensus against risk of stall due
to low participation.


   - Vote will run through 6/24/20
   - pmc votes considered binding
   - simple majority of binding participants passes the vote
   - committer and community votes considered advisory

Lastly, I propose we take the count of pmc votes in this thread as our
initial roll call count for electorate numbers and low watermark
calculation on subsequent votes.

Thanks again everyone (and specifically Benedict and Jon) for the time and
collaboration on this.

~Josh


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Blake Eggleston
+1

> On Jun 20, 2020, at 8:12 AM, Joshua McKenzie  wrote:
> 
> Link to doc:
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> 
> Change since previous cancelled vote:
> "A simple majority of this electorate becomes the low-watermark for votes
> in favour necessary to pass a motion, with new PMC members added to the
> calculation."
> 
> This previously read "super majority". We have lowered the low water mark
> to "simple majority" to balance strong consensus against risk of stall due
> to low participation.
> 
> 
>   - Vote will run through 6/24/20
>   - pmc votes considered binding
>   - simple majority of binding participants passes the vote
>   - committer and community votes considered advisory
> 
> Lastly, I propose we take the count of pmc votes in this thread as our
> initial roll call count for electorate numbers and low watermark
> calculation on subsequent votes.
> 
> Thanks again everyone (and specifically Benedict and Jon) for the time and
> collaboration on this.
> 
> ~Josh


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Joseph Lynch
On Mon, Jun 22, 2020 at 3:23 AM Benedict Elliott Smith
 wrote:
>
> If you read the clauses literally there's no conflict - not all committers 
> that +1 the change need to review the work.  It just means that two 
> committers have indicated they are comfortable with the patch being merged.  
> One of the +1s could be based on another pre-existing review and trust in 
> both the contributor's and reviewer's knowledge of the area; and/or by 
> skimming the patch.  Though they should make it clear that they did not 
> review the patch when +1ing, so there's no ambiguity.

Ah, I understand now, thank you Benedict for explaining. If I
understand correctly the intention is that all patches must be
~"deeply understood" by at least two contributors (author + reviewer)
and one of those contributors must be a comitter. In addition, at
least two committers must support the patch being merged not
necessarily having done a detailed review.

I like the phrase "+1. I support this patch" vs a "+1 I have reviewed
this patch and support it". I suppose that if the +1 is coming from a
person in the reviewer field the "I have reviewed it" is perhaps
implicit.

> Perhaps we should elaborate on the document to avoid this confusion, as this 
> has come up multiple times.

I was confused but now I think I understand it and agree with you that
the wording is not in conflict. After the document is finalized I can
add a FAQ section and, if people think it reasonable, to
https://cassandra.apache.org/doc/latest/development/how_to_commit.html
.

-Joey

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Andrés de la Peña
+1 (nb)

On Mon, 22 Jun 2020 at 17:15, Eric Evans  wrote:

> +0
>
> On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie 
> wrote:
> >
> > Link to doc:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > Change since previous cancelled vote:
> > "A simple majority of this electorate becomes the low-watermark for votes
> > in favour necessary to pass a motion, with new PMC members added to the
> > calculation."
> >
> > This previously read "super majority". We have lowered the low water mark
> > to "simple majority" to balance strong consensus against risk of stall
> due
> > to low participation.
> >
> >
> >- Vote will run through 6/24/20
> >- pmc votes considered binding
> >- simple majority of binding participants passes the vote
> >- committer and community votes considered advisory
> >
> > Lastly, I propose we take the count of pmc votes in this thread as our
> > initial roll call count for electorate numbers and low watermark
> > calculation on subsequent votes.
> >
> > Thanks again everyone (and specifically Benedict and Jon) for the time
> and
> > collaboration on this.
> >
> > ~Josh
>
>
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Eric Evans
+0

On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie  wrote:
>
> Link to doc:
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> Change since previous cancelled vote:
> "A simple majority of this electorate becomes the low-watermark for votes
> in favour necessary to pass a motion, with new PMC members added to the
> calculation."
>
> This previously read "super majority". We have lowered the low water mark
> to "simple majority" to balance strong consensus against risk of stall due
> to low participation.
>
>
>- Vote will run through 6/24/20
>- pmc votes considered binding
>- simple majority of binding participants passes the vote
>- committer and community votes considered advisory
>
> Lastly, I propose we take the count of pmc votes in this thread as our
> initial roll call count for electorate numbers and low watermark
> calculation on subsequent votes.
>
> Thanks again everyone (and specifically Benedict and Jon) for the time and
> collaboration on this.
>
> ~Josh



-- 
Eric Evans
john.eric.ev...@gmail.com

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Aleksey Yeshchenko
+1

> On 20 Jun 2020, at 16:12, Joshua McKenzie  wrote:
> 
> Link to doc:
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> 
> Change since previous cancelled vote:
> "A simple majority of this electorate becomes the low-watermark for votes
> in favour necessary to pass a motion, with new PMC members added to the
> calculation."
> 
> This previously read "super majority". We have lowered the low water mark
> to "simple majority" to balance strong consensus against risk of stall due
> to low participation.
> 
> 
>   - Vote will run through 6/24/20
>   - pmc votes considered binding
>   - simple majority of binding participants passes the vote
>   - committer and community votes considered advisory
> 
> Lastly, I propose we take the count of pmc votes in this thread as our
> initial roll call count for electorate numbers and low watermark
> calculation on subsequent votes.
> 
> Thanks again everyone (and specifically Benedict and Jon) for the time and
> collaboration on this.
> 
> ~Josh


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Benedict Elliott Smith
Also, +1

On 22/06/2020, 11:23, "Benedict Elliott Smith"  wrote:

If you read the clauses literally there's no conflict - not all committers 
that +1 the change need to review the work.  It just means that two committers 
have indicated they are comfortable with the patch being merged.  One of the 
+1s could be based on another pre-existing review and trust in both the 
contributor's and reviewer's knowledge of the area; and/or by skimming the 
patch.  Though they should make it clear that they did not review the patch 
when +1ing, so there's no ambiguity.

Perhaps we should elaborate on the document to avoid this confusion, as 
this has come up multiple times.



On 22/06/2020, 02:56, "Joshua McKenzie"  wrote:

The way I've heard it articulated (and makes sense to me) is that a 2nd
committer skimming a contribution to make sure everything looks 
reasonable
should be sufficient. It's a touch more rigor than we do now (1 contrib 
+ 1
committer) without slowing things down too much. If we can develop a
healthy relationship with git revert on the project as well, this model
should further be de-risked.

Also, on my personal docket is for us to discuss how one becomes a
committer and charting that course in the near future, so hopefully 
we'll
see our committer pool expand in diversity and count to make this less 
of a
burden.

On Sun, Jun 21, 2020 at 7:32 PM Joseph Lynch  
wrote:

> +1 (nb).
>
> Thank you Josh for advocating for these changes!
>
> I am curious about how Code Contribution Guideline #2 reading "Code
> modifications must have been reviewed by at least one other
> contributor" and Guideline #3 reading "Code modifications require two
> +1 committer votes (can be author + reviewer)" will work in practice.
> Specifically, if a contributor submits a ticket reporting a bug with a
> patch attached and then it is reviewed by a committer and committed
> that would appear sufficient under Code Contribution Guideline #2 but
> insufficient under Code Contribution Guideline #3? I'm sorry if this
> was discussed before I just want to make sure going forward I properly
> follow the to be adopted guidelines.
>
> Thanks again!
> -Joey
>
>
> On Sun, Jun 21, 2020 at 8:34 AM Jon Haddad  wrote:
> >
> > +1 binding
> >
> > On Sat, Jun 20, 2020, 11:24 AM Jordan West  
wrote:
> >
> > > +1 (nb)
> > >
> > > On Sat, Jun 20, 2020 at 11:13 AM Jonathan Ellis 

> wrote:
> > >
> > > > +1
> > > >
> > > > On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie <
> jmcken...@apache.org>
> > > > wrote:
> > > >
> > > > > Link to doc:
> > > > >
> > > > >
> > > >
> > >
> 
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > > >
> > > > > Change since previous cancelled vote:
> > > > > "A simple majority of this electorate becomes the 
low-watermark for
> > > votes
> > > > > in favour necessary to pass a motion, with new PMC members 
added
> to the
> > > > > calculation."
> > > > >
> > > > > This previously read "super majority". We have lowered the low
> water
> > > mark
> > > > > to "simple majority" to balance strong consensus against risk 
of
> stall
> > > > due
> > > > > to low participation.
> > > > >
> > > > >
> > > > >- Vote will run through 6/24/20
> > > > >- pmc votes considered binding
> > > > >- simple majority of binding participants passes the vote
> > > > >- committer and community votes considered advisory
> > > > >
> > > > > Lastly, I propose we take the count of pmc votes in this 
thread as
> our
> > > > > initial roll call count for electorate numbers and low 
watermark
> > > > > calculation on subsequent votes.
> > > > >
> > > > > Thanks again everyone (and specifically Benedict and Jon) for 
the
> time
> > > > and
> > > > > collaboration on this.
> > > > >
> > > > > ~Josh
> > > > >
> > > >
> > > >
> > > > --
> > > > Jonathan Ellis
> > > > co-founder, http://www.datastax.com
> > > > @spyced
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>




Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Benedict Elliott Smith
If you read the clauses literally there's no conflict - not all committers that 
+1 the change need to review the work.  It just means that two committers have 
indicated they are comfortable with the patch being merged.  One of the +1s 
could be based on another pre-existing review and trust in both the 
contributor's and reviewer's knowledge of the area; and/or by skimming the 
patch.  Though they should make it clear that they did not review the patch 
when +1ing, so there's no ambiguity.

Perhaps we should elaborate on the document to avoid this confusion, as this 
has come up multiple times.



On 22/06/2020, 02:56, "Joshua McKenzie"  wrote:

The way I've heard it articulated (and makes sense to me) is that a 2nd
committer skimming a contribution to make sure everything looks reasonable
should be sufficient. It's a touch more rigor than we do now (1 contrib + 1
committer) without slowing things down too much. If we can develop a
healthy relationship with git revert on the project as well, this model
should further be de-risked.

Also, on my personal docket is for us to discuss how one becomes a
committer and charting that course in the near future, so hopefully we'll
see our committer pool expand in diversity and count to make this less of a
burden.

On Sun, Jun 21, 2020 at 7:32 PM Joseph Lynch  wrote:

> +1 (nb).
>
> Thank you Josh for advocating for these changes!
>
> I am curious about how Code Contribution Guideline #2 reading "Code
> modifications must have been reviewed by at least one other
> contributor" and Guideline #3 reading "Code modifications require two
> +1 committer votes (can be author + reviewer)" will work in practice.
> Specifically, if a contributor submits a ticket reporting a bug with a
> patch attached and then it is reviewed by a committer and committed
> that would appear sufficient under Code Contribution Guideline #2 but
> insufficient under Code Contribution Guideline #3? I'm sorry if this
> was discussed before I just want to make sure going forward I properly
> follow the to be adopted guidelines.
>
> Thanks again!
> -Joey
>
>
> On Sun, Jun 21, 2020 at 8:34 AM Jon Haddad  wrote:
> >
> > +1 binding
> >
> > On Sat, Jun 20, 2020, 11:24 AM Jordan West  wrote:
> >
> > > +1 (nb)
> > >
> > > On Sat, Jun 20, 2020 at 11:13 AM Jonathan Ellis 
> wrote:
> > >
> > > > +1
> > > >
> > > > On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie <
> jmcken...@apache.org>
> > > > wrote:
> > > >
> > > > > Link to doc:
> > > > >
> > > > >
> > > >
> > >
> 
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > > >
> > > > > Change since previous cancelled vote:
> > > > > "A simple majority of this electorate becomes the low-watermark 
for
> > > votes
> > > > > in favour necessary to pass a motion, with new PMC members added
> to the
> > > > > calculation."
> > > > >
> > > > > This previously read "super majority". We have lowered the low
> water
> > > mark
> > > > > to "simple majority" to balance strong consensus against risk of
> stall
> > > > due
> > > > > to low participation.
> > > > >
> > > > >
> > > > >- Vote will run through 6/24/20
> > > > >- pmc votes considered binding
> > > > >- simple majority of binding participants passes the vote
> > > > >- committer and community votes considered advisory
> > > > >
> > > > > Lastly, I propose we take the count of pmc votes in this thread as
> our
> > > > > initial roll call count for electorate numbers and low watermark
> > > > > calculation on subsequent votes.
> > > > >
> > > > > Thanks again everyone (and specifically Benedict and Jon) for the
> time
> > > > and
> > > > > collaboration on this.
> > > > >
> > > > > ~Josh
> > > > >
> > > >
> > > >
> > > > --
> > > > Jonathan Ellis
> > > > co-founder, http://www.datastax.com
> > > > @spyced
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Sam Tunnicliffe
+1

> On 22 Jun 2020, at 08:54, Sylvain Lebresne  wrote:
> 
> +1
> --
> Sylvain
> 
> 
> On Mon, Jun 22, 2020 at 9:48 AM Benjamin Lerer 
> wrote:
> 
>> +1
>> 
>> On Mon, Jun 22, 2020 at 8:54 AM Marcus Eriksson 
>> wrote:
>> 
>>> +1
>>> 
>>> 
>>> On 22 June 2020 at 08:37:39, Mick Semb Wever (m...@apache.org) wrote:
>>> 
 - Vote will run through 6/24/20
 - pmc votes considered binding
 - simple majority of binding participants passes the vote
 - committer and community votes considered advisory
>>> 
>>> 
>>> 
>>> +1 (binding)
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Sylvain Lebresne
+1
--
Sylvain


On Mon, Jun 22, 2020 at 9:48 AM Benjamin Lerer 
wrote:

> +1
>
> On Mon, Jun 22, 2020 at 8:54 AM Marcus Eriksson 
> wrote:
>
> > +1
> >
> >
> > On 22 June 2020 at 08:37:39, Mick Semb Wever (m...@apache.org) wrote:
> >
> > > - Vote will run through 6/24/20
> > > - pmc votes considered binding
> > > - simple majority of binding participants passes the vote
> > > - committer and community votes considered advisory
> >
> >
> >
> > +1 (binding)
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Benjamin Lerer
+1

On Mon, Jun 22, 2020 at 8:54 AM Marcus Eriksson  wrote:

> +1
>
>
> On 22 June 2020 at 08:37:39, Mick Semb Wever (m...@apache.org) wrote:
>
> > - Vote will run through 6/24/20
> > - pmc votes considered binding
> > - simple majority of binding participants passes the vote
> > - committer and community votes considered advisory
>
>
>
> +1 (binding)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Marcus Eriksson
+1


On 22 June 2020 at 08:37:39, Mick Semb Wever (m...@apache.org) wrote:

> - Vote will run through 6/24/20 
> - pmc votes considered binding 
> - simple majority of binding participants passes the vote 
> - committer and community votes considered advisory 



+1 (binding) 

- 
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org 
For additional commands, e-mail: dev-h...@cassandra.apache.org 



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-22 Thread Mick Semb Wever
>- Vote will run through 6/24/20
>- pmc votes considered binding
>- simple majority of binding participants passes the vote
>- committer and community votes considered advisory



+1 (binding)

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-21 Thread Joshua McKenzie
The way I've heard it articulated (and makes sense to me) is that a 2nd
committer skimming a contribution to make sure everything looks reasonable
should be sufficient. It's a touch more rigor than we do now (1 contrib + 1
committer) without slowing things down too much. If we can develop a
healthy relationship with git revert on the project as well, this model
should further be de-risked.

Also, on my personal docket is for us to discuss how one becomes a
committer and charting that course in the near future, so hopefully we'll
see our committer pool expand in diversity and count to make this less of a
burden.

On Sun, Jun 21, 2020 at 7:32 PM Joseph Lynch  wrote:

> +1 (nb).
>
> Thank you Josh for advocating for these changes!
>
> I am curious about how Code Contribution Guideline #2 reading "Code
> modifications must have been reviewed by at least one other
> contributor" and Guideline #3 reading "Code modifications require two
> +1 committer votes (can be author + reviewer)" will work in practice.
> Specifically, if a contributor submits a ticket reporting a bug with a
> patch attached and then it is reviewed by a committer and committed
> that would appear sufficient under Code Contribution Guideline #2 but
> insufficient under Code Contribution Guideline #3? I'm sorry if this
> was discussed before I just want to make sure going forward I properly
> follow the to be adopted guidelines.
>
> Thanks again!
> -Joey
>
>
> On Sun, Jun 21, 2020 at 8:34 AM Jon Haddad  wrote:
> >
> > +1 binding
> >
> > On Sat, Jun 20, 2020, 11:24 AM Jordan West  wrote:
> >
> > > +1 (nb)
> > >
> > > On Sat, Jun 20, 2020 at 11:13 AM Jonathan Ellis 
> wrote:
> > >
> > > > +1
> > > >
> > > > On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie <
> jmcken...@apache.org>
> > > > wrote:
> > > >
> > > > > Link to doc:
> > > > >
> > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > > >
> > > > > Change since previous cancelled vote:
> > > > > "A simple majority of this electorate becomes the low-watermark for
> > > votes
> > > > > in favour necessary to pass a motion, with new PMC members added
> to the
> > > > > calculation."
> > > > >
> > > > > This previously read "super majority". We have lowered the low
> water
> > > mark
> > > > > to "simple majority" to balance strong consensus against risk of
> stall
> > > > due
> > > > > to low participation.
> > > > >
> > > > >
> > > > >- Vote will run through 6/24/20
> > > > >- pmc votes considered binding
> > > > >- simple majority of binding participants passes the vote
> > > > >- committer and community votes considered advisory
> > > > >
> > > > > Lastly, I propose we take the count of pmc votes in this thread as
> our
> > > > > initial roll call count for electorate numbers and low watermark
> > > > > calculation on subsequent votes.
> > > > >
> > > > > Thanks again everyone (and specifically Benedict and Jon) for the
> time
> > > > and
> > > > > collaboration on this.
> > > > >
> > > > > ~Josh
> > > > >
> > > >
> > > >
> > > > --
> > > > Jonathan Ellis
> > > > co-founder, http://www.datastax.com
> > > > @spyced
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-21 Thread Nate McCall
+1

On Sun, Jun 21, 2020 at 3:12 AM Joshua McKenzie 
wrote:

> Link to doc:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> Change since previous cancelled vote:
> "A simple majority of this electorate becomes the low-watermark for votes
> in favour necessary to pass a motion, with new PMC members added to the
> calculation."
>
> This previously read "super majority". We have lowered the low water mark
> to "simple majority" to balance strong consensus against risk of stall due
> to low participation.
>
>
>- Vote will run through 6/24/20
>- pmc votes considered binding
>- simple majority of binding participants passes the vote
>- committer and community votes considered advisory
>
> Lastly, I propose we take the count of pmc votes in this thread as our
> initial roll call count for electorate numbers and low watermark
> calculation on subsequent votes.
>
> Thanks again everyone (and specifically Benedict and Jon) for the time and
> collaboration on this.
>
> ~Josh
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-21 Thread Joseph Lynch
+1 (nb).

Thank you Josh for advocating for these changes!

I am curious about how Code Contribution Guideline #2 reading "Code
modifications must have been reviewed by at least one other
contributor" and Guideline #3 reading "Code modifications require two
+1 committer votes (can be author + reviewer)" will work in practice.
Specifically, if a contributor submits a ticket reporting a bug with a
patch attached and then it is reviewed by a committer and committed
that would appear sufficient under Code Contribution Guideline #2 but
insufficient under Code Contribution Guideline #3? I'm sorry if this
was discussed before I just want to make sure going forward I properly
follow the to be adopted guidelines.

Thanks again!
-Joey


On Sun, Jun 21, 2020 at 8:34 AM Jon Haddad  wrote:
>
> +1 binding
>
> On Sat, Jun 20, 2020, 11:24 AM Jordan West  wrote:
>
> > +1 (nb)
> >
> > On Sat, Jun 20, 2020 at 11:13 AM Jonathan Ellis  wrote:
> >
> > > +1
> > >
> > > On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie 
> > > wrote:
> > >
> > > > Link to doc:
> > > >
> > > >
> > >
> > https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > >
> > > > Change since previous cancelled vote:
> > > > "A simple majority of this electorate becomes the low-watermark for
> > votes
> > > > in favour necessary to pass a motion, with new PMC members added to the
> > > > calculation."
> > > >
> > > > This previously read "super majority". We have lowered the low water
> > mark
> > > > to "simple majority" to balance strong consensus against risk of stall
> > > due
> > > > to low participation.
> > > >
> > > >
> > > >- Vote will run through 6/24/20
> > > >- pmc votes considered binding
> > > >- simple majority of binding participants passes the vote
> > > >- committer and community votes considered advisory
> > > >
> > > > Lastly, I propose we take the count of pmc votes in this thread as our
> > > > initial roll call count for electorate numbers and low watermark
> > > > calculation on subsequent votes.
> > > >
> > > > Thanks again everyone (and specifically Benedict and Jon) for the time
> > > and
> > > > collaboration on this.
> > > >
> > > > ~Josh
> > > >
> > >
> > >
> > > --
> > > Jonathan Ellis
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-21 Thread Jon Haddad
+1 binding

On Sat, Jun 20, 2020, 11:24 AM Jordan West  wrote:

> +1 (nb)
>
> On Sat, Jun 20, 2020 at 11:13 AM Jonathan Ellis  wrote:
>
> > +1
> >
> > On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie 
> > wrote:
> >
> > > Link to doc:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > >
> > > Change since previous cancelled vote:
> > > "A simple majority of this electorate becomes the low-watermark for
> votes
> > > in favour necessary to pass a motion, with new PMC members added to the
> > > calculation."
> > >
> > > This previously read "super majority". We have lowered the low water
> mark
> > > to "simple majority" to balance strong consensus against risk of stall
> > due
> > > to low participation.
> > >
> > >
> > >- Vote will run through 6/24/20
> > >- pmc votes considered binding
> > >- simple majority of binding participants passes the vote
> > >- committer and community votes considered advisory
> > >
> > > Lastly, I propose we take the count of pmc votes in this thread as our
> > > initial roll call count for electorate numbers and low watermark
> > > calculation on subsequent votes.
> > >
> > > Thanks again everyone (and specifically Benedict and Jon) for the time
> > and
> > > collaboration on this.
> > >
> > > ~Josh
> > >
> >
> >
> > --
> > Jonathan Ellis
> > co-founder, http://www.datastax.com
> > @spyced
> >
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Jordan West
+1 (nb)

On Sat, Jun 20, 2020 at 11:13 AM Jonathan Ellis  wrote:

> +1
>
> On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie 
> wrote:
>
> > Link to doc:
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > Change since previous cancelled vote:
> > "A simple majority of this electorate becomes the low-watermark for votes
> > in favour necessary to pass a motion, with new PMC members added to the
> > calculation."
> >
> > This previously read "super majority". We have lowered the low water mark
> > to "simple majority" to balance strong consensus against risk of stall
> due
> > to low participation.
> >
> >
> >- Vote will run through 6/24/20
> >- pmc votes considered binding
> >- simple majority of binding participants passes the vote
> >- committer and community votes considered advisory
> >
> > Lastly, I propose we take the count of pmc votes in this thread as our
> > initial roll call count for electorate numbers and low watermark
> > calculation on subsequent votes.
> >
> > Thanks again everyone (and specifically Benedict and Jon) for the time
> and
> > collaboration on this.
> >
> > ~Josh
> >
>
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Jonathan Ellis
+1

On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie 
wrote:

> Link to doc:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> Change since previous cancelled vote:
> "A simple majority of this electorate becomes the low-watermark for votes
> in favour necessary to pass a motion, with new PMC members added to the
> calculation."
>
> This previously read "super majority". We have lowered the low water mark
> to "simple majority" to balance strong consensus against risk of stall due
> to low participation.
>
>
>- Vote will run through 6/24/20
>- pmc votes considered binding
>- simple majority of binding participants passes the vote
>- committer and community votes considered advisory
>
> Lastly, I propose we take the count of pmc votes in this thread as our
> initial roll call count for electorate numbers and low watermark
> calculation on subsequent votes.
>
> Thanks again everyone (and specifically Benedict and Jon) for the time and
> collaboration on this.
>
> ~Josh
>


-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Yifan Cai
+1 nb


From: Scott Andreas 
Sent: Saturday, June 20, 2020 11:00:15 AM
To: dev@cassandra.apache.org 
Subject: Re: [VOTE] Project governance wiki doc (take 2)

+1 nb

> On Jun 20, 2020, at 9:37 AM, Joshua McKenzie  wrote:
>
> +1 (binding / present / active)
>
> On Sat, Jun 20, 2020 at 12:23 PM Ekaterina Dimitrova 
> wrote:
>
>> +1(non-binding)
>>
>> On Sat, 20 Jun 2020 at 11:38, Brandon Williams  wrote:
>>
>>> +1
>>>
>>> On Sat, Jun 20, 2020, 10:12 AM Joshua McKenzie 
>>> wrote:
>>>
>>>> Link to doc:
>>>>
>>>>
>>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>>>>
>>>> Change since previous cancelled vote:
>>>> "A simple majority of this electorate becomes the low-watermark for
>> votes
>>>> in favour necessary to pass a motion, with new PMC members added to the
>>>> calculation."
>>>>
>>>> This previously read "super majority". We have lowered the low water
>> mark
>>>> to "simple majority" to balance strong consensus against risk of stall
>>> due
>>>> to low participation.
>>>>
>>>>
>>>>   - Vote will run through 6/24/20
>>>>   - pmc votes considered binding
>>>>   - simple majority of binding participants passes the vote
>>>>   - committer and community votes considered advisory
>>>>
>>>> Lastly, I propose we take the count of pmc votes in this thread as our
>>>> initial roll call count for electorate numbers and low watermark
>>>> calculation on subsequent votes.
>>>>
>>>> Thanks again everyone (and specifically Benedict and Jon) for the time
>>> and
>>>> collaboration on this.
>>>>
>>>> ~Josh
>>>>
>>>
>>


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Scott Andreas
+1 nb

> On Jun 20, 2020, at 9:37 AM, Joshua McKenzie  wrote:
> 
> +1 (binding / present / active)
> 
> On Sat, Jun 20, 2020 at 12:23 PM Ekaterina Dimitrova 
> wrote:
> 
>> +1(non-binding)
>> 
>> On Sat, 20 Jun 2020 at 11:38, Brandon Williams  wrote:
>> 
>>> +1
>>> 
>>> On Sat, Jun 20, 2020, 10:12 AM Joshua McKenzie 
>>> wrote:
>>> 
 Link to doc:
 
 
>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
 
 Change since previous cancelled vote:
 "A simple majority of this electorate becomes the low-watermark for
>> votes
 in favour necessary to pass a motion, with new PMC members added to the
 calculation."
 
 This previously read "super majority". We have lowered the low water
>> mark
 to "simple majority" to balance strong consensus against risk of stall
>>> due
 to low participation.
 
 
   - Vote will run through 6/24/20
   - pmc votes considered binding
   - simple majority of binding participants passes the vote
   - committer and community votes considered advisory
 
 Lastly, I propose we take the count of pmc votes in this thread as our
 initial roll call count for electorate numbers and low watermark
 calculation on subsequent votes.
 
 Thanks again everyone (and specifically Benedict and Jon) for the time
>>> and
 collaboration on this.
 
 ~Josh
 
>>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Joshua McKenzie
+1 (binding / present / active)

On Sat, Jun 20, 2020 at 12:23 PM Ekaterina Dimitrova 
wrote:

> +1(non-binding)
>
> On Sat, 20 Jun 2020 at 11:38, Brandon Williams  wrote:
>
> > +1
> >
> > On Sat, Jun 20, 2020, 10:12 AM Joshua McKenzie 
> > wrote:
> >
> > > Link to doc:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > >
> > > Change since previous cancelled vote:
> > > "A simple majority of this electorate becomes the low-watermark for
> votes
> > > in favour necessary to pass a motion, with new PMC members added to the
> > > calculation."
> > >
> > > This previously read "super majority". We have lowered the low water
> mark
> > > to "simple majority" to balance strong consensus against risk of stall
> > due
> > > to low participation.
> > >
> > >
> > >- Vote will run through 6/24/20
> > >- pmc votes considered binding
> > >- simple majority of binding participants passes the vote
> > >- committer and community votes considered advisory
> > >
> > > Lastly, I propose we take the count of pmc votes in this thread as our
> > > initial roll call count for electorate numbers and low watermark
> > > calculation on subsequent votes.
> > >
> > > Thanks again everyone (and specifically Benedict and Jon) for the time
> > and
> > > collaboration on this.
> > >
> > > ~Josh
> > >
> >
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Ekaterina Dimitrova
+1(non-binding)

On Sat, 20 Jun 2020 at 11:38, Brandon Williams  wrote:

> +1
>
> On Sat, Jun 20, 2020, 10:12 AM Joshua McKenzie 
> wrote:
>
> > Link to doc:
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > Change since previous cancelled vote:
> > "A simple majority of this electorate becomes the low-watermark for votes
> > in favour necessary to pass a motion, with new PMC members added to the
> > calculation."
> >
> > This previously read "super majority". We have lowered the low water mark
> > to "simple majority" to balance strong consensus against risk of stall
> due
> > to low participation.
> >
> >
> >- Vote will run through 6/24/20
> >- pmc votes considered binding
> >- simple majority of binding participants passes the vote
> >- committer and community votes considered advisory
> >
> > Lastly, I propose we take the count of pmc votes in this thread as our
> > initial roll call count for electorate numbers and low watermark
> > calculation on subsequent votes.
> >
> > Thanks again everyone (and specifically Benedict and Jon) for the time
> and
> > collaboration on this.
> >
> > ~Josh
> >
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Brandon Williams
+1

On Sat, Jun 20, 2020, 10:12 AM Joshua McKenzie  wrote:

> Link to doc:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> Change since previous cancelled vote:
> "A simple majority of this electorate becomes the low-watermark for votes
> in favour necessary to pass a motion, with new PMC members added to the
> calculation."
>
> This previously read "super majority". We have lowered the low water mark
> to "simple majority" to balance strong consensus against risk of stall due
> to low participation.
>
>
>- Vote will run through 6/24/20
>- pmc votes considered binding
>- simple majority of binding participants passes the vote
>- committer and community votes considered advisory
>
> Lastly, I propose we take the count of pmc votes in this thread as our
> initial roll call count for electorate numbers and low watermark
> calculation on subsequent votes.
>
> Thanks again everyone (and specifically Benedict and Jon) for the time and
> collaboration on this.
>
> ~Josh
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Jasonstack Zhao Yang
+1 (nb)

On Sat, 20 Jun 2020 at 23:18, Jeff Jirsa  wrote:

> +1 (and present?)
>
>
> > On Jun 20, 2020, at 8:12 AM, Joshua McKenzie 
> wrote:
> >
> > Link to doc:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > Change since previous cancelled vote:
> > "A simple majority of this electorate becomes the low-watermark for votes
> > in favour necessary to pass a motion, with new PMC members added to the
> > calculation."
> >
> > This previously read "super majority". We have lowered the low water mark
> > to "simple majority" to balance strong consensus against risk of stall
> due
> > to low participation.
> >
> >
> >   - Vote will run through 6/24/20
> >   - pmc votes considered binding
> >   - simple majority of binding participants passes the vote
> >   - committer and community votes considered advisory
> >
> > Lastly, I propose we take the count of pmc votes in this thread as our
> > initial roll call count for electorate numbers and low watermark
> > calculation on subsequent votes.
> >
> > Thanks again everyone (and specifically Benedict and Jon) for the time
> and
> > collaboration on this.
> >
> > ~Josh
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Jeff Jirsa
+1 (and present?) 


> On Jun 20, 2020, at 8:12 AM, Joshua McKenzie  wrote:
> 
> Link to doc:
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> 
> Change since previous cancelled vote:
> "A simple majority of this electorate becomes the low-watermark for votes
> in favour necessary to pass a motion, with new PMC members added to the
> calculation."
> 
> This previously read "super majority". We have lowered the low water mark
> to "simple majority" to balance strong consensus against risk of stall due
> to low participation.
> 
> 
>   - Vote will run through 6/24/20
>   - pmc votes considered binding
>   - simple majority of binding participants passes the vote
>   - committer and community votes considered advisory
> 
> Lastly, I propose we take the count of pmc votes in this thread as our
> initial roll call count for electorate numbers and low watermark
> calculation on subsequent votes.
> 
> Thanks again everyone (and specifically Benedict and Jon) for the time and
> collaboration on this.
> 
> ~Josh

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[VOTE] Project governance wiki doc (take 2)

2020-06-20 Thread Joshua McKenzie
Link to doc:
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance

Change since previous cancelled vote:
"A simple majority of this electorate becomes the low-watermark for votes
in favour necessary to pass a motion, with new PMC members added to the
calculation."

This previously read "super majority". We have lowered the low water mark
to "simple majority" to balance strong consensus against risk of stall due
to low participation.


   - Vote will run through 6/24/20
   - pmc votes considered binding
   - simple majority of binding participants passes the vote
   - committer and community votes considered advisory

Lastly, I propose we take the count of pmc votes in this thread as our
initial roll call count for electorate numbers and low watermark
calculation on subsequent votes.

Thanks again everyone (and specifically Benedict and Jon) for the time and
collaboration on this.

~Josh


Re: [VOTE] Project governance wiki doc

2020-06-19 Thread Joshua McKenzie
   > > find ourselves in a position where we are unable to change
>> the
>> > > voting rules
>> > > > due to the bar being too high.  I may be in the minority
>> here
>> > > though.  I'm
>> > > > extremely curious if this process would have enough votes to
>> > pass the
>> > > > proposed voting guidelines, because if it doesn't, I don't
>> see
>> > the
>> > > point in
>> > > > adopting them.  Again, my opinion might not be shared by
>> > everyone
>> > > else.
>> > > >
>> > > > I'm sticking with my -1 on the doc as-is.
>> > > >
>> > > > Thanks,
>> > > > Jon
>> > > >
>> > > > On Thu, Jun 18, 2020 at 8:17 AM Joshua McKenzie <
>> > > jmcken...@apache.org>
>> > > > wrote:
>> > > >
>> > > > > One follow up thought - if we're considering this vote
>> simple
>> > > majority,
>> > > > or
>> > > > > super majority of participants, it's passing and we can
>> just
>> > > follow up
>> > > > > w/revisions on a subsequent vote. I personally would
>> prefer
>> > we go
>> > > that
>> > > > > route; we all need to internalize that moving forward and
>> > > incrementally
>> > > > > revising things is Safe and OK. :)
>> > > > >
>> > > > > ~Josh
>> > > > >
>> > > > > On Thu, Jun 18, 2020 at 10:00 AM Joshua McKenzie <
>> > > jmcken...@apache.org>
>> > > > > wrote:
>> > > > >
>> > > > > > So did you two come to an agreement? I must have
>> misread:
>> > > > > >
>> > > > > > changing the minimum number of votes to be a simple
>> > > > > >> majority of the number of people participating in the
>> roll
>> > > call.  For
>> > > > > >> example, if we have a roll call of 21, then we'll need
>> a
>> > > minimum of 11
>> > > > > >> binding votes participating.  Of that 11, we'd need 2/3
>> > to be
>> >     > +1 to
>> > > > > pass,
>> > > > > >> so in that case 8 +1's.
>> > > > > >
>> > > > > >
>> > > > > > I guess we should visit this again afterwards, as this
>> > isn't
>> > > what I
>> > > > > >> intended.
>> > > > > >
>> > > > > >
>> > > > > > I have little interest in changing any of the doc as
>> > written as
>> > > > reflected
>> > > > > > by my +1 vote. :)
>> > > > > >
>> > > > > > If you two could come to an agreement and articulate it
>> /
>> > modify
>> > > the
>> > > > wiki
>> > > > > > to reflect it, we can review as a community and vote
>> again.
>> > > > > >
>> > > > > > Also, we should clarify the metrics by which the vote
>> will
>> > pass
>> > > which I
>> > > > > > didn't above. i.e. Simple Majority binding participants,
>> > > Consensus from
>> > > > > > binding (no -1), etc. I'd advocate for simple majority
>> > since
>> > > none of
>> > > > this
>> > > > > > is set in stone and at this point I believe we're
>> > bikeshedding
>> > > against
>> > > > > > something that would be a non-issue assuming positive
>> > intent and
>> > > > > alignment
>> > > > > > between response to roll call and participation.
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai <
>> &g

Re: [VOTE] Project governance wiki doc

2020-06-18 Thread Joshua McKenzie
> > > > Thanks,
> > > > Jon
> > > >
> > > > On Thu, Jun 18, 2020 at 8:17 AM Joshua McKenzie <
> > > jmcken...@apache.org>
> > > > wrote:
> > > >
> > > > > One follow up thought - if we're considering this vote
> simple
> > > majority,
> > > > or
> > > > > super majority of participants, it's passing and we can
> just
> > > follow up
> > > > > w/revisions on a subsequent vote. I personally would prefer
> > we go
> > > that
> > > > > route; we all need to internalize that moving forward and
> > > incrementally
> > > > > revising things is Safe and OK. :)
> > > > >
> > > > > ~Josh
> > > > >
> > > > > On Thu, Jun 18, 2020 at 10:00 AM Joshua McKenzie <
> > > jmcken...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > So did you two come to an agreement? I must have misread:
> > > > > >
> > > > > > changing the minimum number of votes to be a simple
> > > > > >> majority of the number of people participating in the
> roll
> > > call.  For
> > > > > >> example, if we have a roll call of 21, then we'll need a
> > > minimum of 11
> > > > > >> binding votes participating.  Of that 11, we'd need 2/3
> > to be
> > > +1 to
> > > > > pass,
> > > > > >> so in that case 8 +1's.
> > > > > >
> > > > > >
> > > > > > I guess we should visit this again afterwards, as this
> > isn't
> > > what I
> > > > > >> intended.
> > > > > >
> > > > > >
> > >     > > > I have little interest in changing any of the doc as
> > written as
> > > > reflected
> > > > > > by my +1 vote. :)
> > > > > >
> > > > > > If you two could come to an agreement and articulate it /
> > modify
> > > the
> > > > wiki
> > > > > > to reflect it, we can review as a community and vote
> again.
> > > > > >
> > > > > > Also, we should clarify the metrics by which the vote
> will
> > pass
> > > which I
> > > > > > didn't above. i.e. Simple Majority binding participants,
> > > Consensus from
> > > > > > binding (no -1), etc. I'd advocate for simple majority
> > since
> > > none of
> > > > this
> > > > > > is set in stone and at this point I believe we're
> > bikeshedding
> > > against
> > > > > > something that would be a non-issue assuming positive
> > intent and
> > > > > alignment
> > > > > > between response to roll call and participation.
> > > > > >
> > > > > >
> > > > > > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai <
> > yc25c...@gmail.com>
> > > wrote:
> > > > > >
> > > > > >> +1 nb
> > > > > >> 
> > > > > >> From: Jon Haddad 
> > > > > >> Sent: Wednesday, June 17, 2020 2:13 PM
> > > > > >> To: dev@cassandra.apache.org
> > > > > >> Subject: Re: [VOTE] Project governance wiki doc
> > > > > >>
> > > > > >> Yes, this is my understanding as well.
> > > > > >>
> > > > > >>
> > > > > >> On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith <
> > > > > >> bened...@apache.org>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > I personally think we should not revisit the
> > super-majority
> > > of votes
> > > > > >> >

Re: [VOTE] Project governance wiki doc

2020-06-18 Thread Jon Haddad
   > > >
> > > > > changing the minimum number of votes to be a simple
> > > > >> majority of the number of people participating in the roll
> > call.  For
> > > > >> example, if we have a roll call of 21, then we'll need a
> > minimum of 11
> > > > >> binding votes participating.  Of that 11, we'd need 2/3
> to be
> > +1 to
> > > > pass,
> > > > >> so in that case 8 +1's.
> > > > >
> > > > >
> > > > > I guess we should visit this again afterwards, as this
> isn't
> > what I
> > > > >> intended.
> > > > >
> > > > >
> > > > > I have little interest in changing any of the doc as
> written as
> > > reflected
> > > > > by my +1 vote. :)
> > > > >
> > > > > If you two could come to an agreement and articulate it /
> modify
> > the
> > > wiki
>     > > > > to reflect it, we can review as a community and vote again.
> > > > >
> > > > > Also, we should clarify the metrics by which the vote will
> pass
> > which I
> > > > > didn't above. i.e. Simple Majority binding participants,
> > Consensus from
> > > > > binding (no -1), etc. I'd advocate for simple majority
> since
> > none of
> > > this
> > > > > is set in stone and at this point I believe we're
> bikeshedding
> > against
> > > > > something that would be a non-issue assuming positive
> intent and
> > > > alignment
> > > > > between response to roll call and participation.
> > > > >
> > > > >
> > > > > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai <
> yc25c...@gmail.com>
> > wrote:
> > > > >
> > > > >> +1 nb
> > > > >> 
> > > > >> From: Jon Haddad 
> > > > >> Sent: Wednesday, June 17, 2020 2:13 PM
> > > > >> To: dev@cassandra.apache.org
> > > > >> Subject: Re: [VOTE] Project governance wiki doc
> > > > >>
> > > > >> Yes, this is my understanding as well.
> > > > >>
> > > > >>
> > > > >> On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith <
> > > > >> bened...@apache.org>
> > > > >> wrote:
> > > > >>
> > > > >> > I personally think we should not revisit the
> super-majority
> > of votes
> > > > >> > decision, as that was settled already; simple-majority
> came a
> > > distant
> > > > >> > third.  Since this question doesn't really invalidate
> that
> > > decision, I
> > > > >> > think for forward progress it's better to simply
> address the
> > vote
> > > > floor,
> > > > >> > but just my 2c.
> > > > >> >
> > > > >> > On 17/06/2020, 21:58, "Jon Haddad" 
> > wrote:
> > > > >> >
> > > > >> > For what it's worth, I thought Benedict's
> suggestion was a
> > > pretty
> > > > >> > reasonable one and am in favor of it.
> > > > >> >
> > > > >> > On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie <
> > > > >> jmcken...@apache.org>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Race condition on that last one Benedict.
> > > > >> > >
> > > > >> > > What about using the quorum from roll call to
> simply
> > define
> > > how
> > > > >> many
> > > > >> > +1's
> > > > >> > > are needed to pass something? Simple majority of
> the
>  

Re: [VOTE] Project governance wiki doc

2020-06-18 Thread Benedict Elliott Smith
 > >
> > > > I have little interest in changing any of the doc as written as
> > reflected
> > > > by my +1 vote. :)
> > > >
> > > > If you two could come to an agreement and articulate it / modify
> the
> > wiki
> > > > to reflect it, we can review as a community and vote again.
> > > >
> > > > Also, we should clarify the metrics by which the vote will pass
> which I
> > > > didn't above. i.e. Simple Majority binding participants,
> Consensus from
> > > > binding (no -1), etc. I'd advocate for simple majority since
> none of
> > this
> > > > is set in stone and at this point I believe we're bikeshedding
> against
> > > > something that would be a non-issue assuming positive intent and
> > > alignment
> > > > between response to roll call and participation.
> > > >
> > > >
> > > > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai 
> wrote:
> > > >
> > > >> +1 nb
> > > >> 
> > > >> From: Jon Haddad 
> > > >> Sent: Wednesday, June 17, 2020 2:13 PM
> > > >> To: dev@cassandra.apache.org
> > > >> Subject: Re: [VOTE] Project governance wiki doc
> > > >>
> > > >> Yes, this is my understanding as well.
> > > >>
> > > >>
> > > >> On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith <
> > > >> bened...@apache.org>
> > > >> wrote:
> > > >>
> > > >> > I personally think we should not revisit the super-majority
> of votes
> > > >> > decision, as that was settled already; simple-majority came a
> > distant
> > > >> > third.  Since this question doesn't really invalidate that
> > decision, I
> > > >> > think for forward progress it's better to simply address the
> vote
> > > floor,
> > > >> > but just my 2c.
> > > >> >
> > > >> > On 17/06/2020, 21:58, "Jon Haddad" 
> wrote:
> > > >> >
> > > >> > For what it's worth, I thought Benedict's suggestion was 
a
> > pretty
> > > >> > reasonable one and am in favor of it.
> > > >> >
> > > >> > On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie <
> > > >> jmcken...@apache.org>
> > > >> > wrote:
> > > >> >
> > > >> > > Race condition on that last one Benedict.
> > > >> > >
> > > >> > > What about using the quorum from roll call to simply
> define
> > how
> > > >> many
> > > >> > +1's
> > > >> > > are needed to pass something? Simple majority of the
> roll
> > call,
> > > >> > simple
> > > >> > > majority of total participants on specific vote and it
> passes?
> > > >> > >
> > > >> > > For example:
> > > >> > >
> > > >> > >- 33 pmc members
> > > >> > >- 16 roll call
> > > >> > >- 9 +1's required. If only participation is 9 vote
> with +1,
> > > >> passes
> > > >> > >- If 9 +1's and 10 -1's, does not pass
> > > >> > >
> > > >> > > That prevents the "abstain to keep vote invalid" while
> keeping
> > > >> with
> > > >> > the
> > > >> > > lazy consensus spirit and requiring enough
> participation that
> > a
> > > >> vote
> > > >> > should
> > > >> > > reasonably be considered indicative. Does raise the bar
> a

Re: [VOTE] Project governance wiki doc

2020-06-18 Thread Jon Haddad
Yes... it is a bit awkward.  It's why I was originally in favor of
increasing the minimum threshold to 7 & go to super majority.  It's more
than what we do now, but not so much that I think we'll end up backed into
a corner.  I didn't do a good job of explaining that though.

Might be useful to take a roll call now just to get a feel for what we're
voting for.

On Thu, Jun 18, 2020 at 11:21 AM Benedict Elliott Smith 
wrote:

> It does raise the question of how we would conduct a vote immediately
> afterwards - would the vote floor be temporarily be zero, since we've
> conducted no roll calls?  Perhaps we should indicate in the next vote we
> call on the rules, that votes will also serve as the initial roll call.
>
> Also, we did discuss having mechanisms to ensure we can "vote our way out"
> e.g. by permitting a new roll call if we fail to pass several votes in a
> row.
>
> On 18/06/2020, 18:58, "Joshua McKenzie"  wrote:
>
> I'm formally stopping the vote. Jon, please revise the wiki.
>
> Good point about getting ourselves stuck into a corner we couldn't vote
> ourselves back out of. That'd just be silly.
>
> On Thu, Jun 18, 2020 at 12:19 PM Jon Haddad  wrote:
>
> > > If you two could come to an agreement and articulate it / modify
> the
> > wiki to reflect it, we can review as a community and vote again.
> >
> > Since you started the vote, it would be up to you to stop it so we
> can
> > modify the doc.  I don't feel comfortable modifying a doc mid-vote,
> it's
> > not fair to those that have voted, and I don't like introducing
> > inconsistency into our voting.
> >
> > Since we're still governed by the Apache rules, this is a simple
> majority
> > vote requiring a minimum 3 +1's.
> >
> > I am very concerned that if we raise the bar for voting too high, we
> will
> > find ourselves in a position where we are unable to change the
> voting rules
> > due to the bar being too high.  I may be in the minority here
> though.  I'm
> > extremely curious if this process would have enough votes to pass the
> > proposed voting guidelines, because if it doesn't, I don't see the
> point in
> > adopting them.  Again, my opinion might not be shared by everyone
> else.
> >
> > I'm sticking with my -1 on the doc as-is.
> >
> > Thanks,
> > Jon
> >
> > On Thu, Jun 18, 2020 at 8:17 AM Joshua McKenzie <
> jmcken...@apache.org>
> > wrote:
> >
> > > One follow up thought - if we're considering this vote simple
> majority,
> > or
> > > super majority of participants, it's passing and we can just
> follow up
> > > w/revisions on a subsequent vote. I personally would prefer we go
> that
> > > route; we all need to internalize that moving forward and
> incrementally
> > > revising things is Safe and OK. :)
> > >
> > > ~Josh
> > >
> > > On Thu, Jun 18, 2020 at 10:00 AM Joshua McKenzie <
> jmcken...@apache.org>
> > > wrote:
> > >
> > > > So did you two come to an agreement? I must have misread:
> > > >
> > > > changing the minimum number of votes to be a simple
> > > >> majority of the number of people participating in the roll
> call.  For
> > > >> example, if we have a roll call of 21, then we'll need a
> minimum of 11
> > > >> binding votes participating.  Of that 11, we'd need 2/3 to be
> +1 to
> > > pass,
> > > >> so in that case 8 +1's.
> > > >
> > > >
> > > > I guess we should visit this again afterwards, as this isn't
> what I
> > > >> intended.
> > > >
> > > >
> > > > I have little interest in changing any of the doc as written as
> > reflected
> > > > by my +1 vote. :)
> > > >
> > > > If you two could come to an agreement and articulate it / modify
> the
> > wiki
> > > > to reflect it, we can review as a community and vote again.
> > > >
> > > > Also, we should clarify the metrics by which the vote will pass
> which I
> > > > didn't above. i.e. Simple Majority binding participants,
> Consensus from
> > > > binding (no -1), etc. I'd advocate for simple majority since
> none of
> > this
> > > > is set in stone and 

Re: [VOTE] Project governance wiki doc

2020-06-18 Thread Benedict Elliott Smith
It does raise the question of how we would conduct a vote immediately 
afterwards - would the vote floor be temporarily be zero, since we've conducted 
no roll calls?  Perhaps we should indicate in the next vote we call on the 
rules, that votes will also serve as the initial roll call.

Also, we did discuss having mechanisms to ensure we can "vote our way out" e.g. 
by permitting a new roll call if we fail to pass several votes in a row.

On 18/06/2020, 18:58, "Joshua McKenzie"  wrote:

I'm formally stopping the vote. Jon, please revise the wiki.

Good point about getting ourselves stuck into a corner we couldn't vote
ourselves back out of. That'd just be silly.

On Thu, Jun 18, 2020 at 12:19 PM Jon Haddad  wrote:

> > If you two could come to an agreement and articulate it / modify the
> wiki to reflect it, we can review as a community and vote again.
>
> Since you started the vote, it would be up to you to stop it so we can
> modify the doc.  I don't feel comfortable modifying a doc mid-vote, it's
> not fair to those that have voted, and I don't like introducing
> inconsistency into our voting.
>
> Since we're still governed by the Apache rules, this is a simple majority
> vote requiring a minimum 3 +1's.
>
> I am very concerned that if we raise the bar for voting too high, we will
> find ourselves in a position where we are unable to change the voting 
rules
> due to the bar being too high.  I may be in the minority here though.  I'm
> extremely curious if this process would have enough votes to pass the
> proposed voting guidelines, because if it doesn't, I don't see the point 
in
> adopting them.  Again, my opinion might not be shared by everyone else.
>
> I'm sticking with my -1 on the doc as-is.
>
> Thanks,
> Jon
>
> On Thu, Jun 18, 2020 at 8:17 AM Joshua McKenzie 
> wrote:
>
> > One follow up thought - if we're considering this vote simple majority,
> or
> > super majority of participants, it's passing and we can just follow up
> > w/revisions on a subsequent vote. I personally would prefer we go that
> > route; we all need to internalize that moving forward and incrementally
> > revising things is Safe and OK. :)
> >
> > ~Josh
> >
> > On Thu, Jun 18, 2020 at 10:00 AM Joshua McKenzie 
> > wrote:
> >
> > > So did you two come to an agreement? I must have misread:
> > >
> > > changing the minimum number of votes to be a simple
> > >> majority of the number of people participating in the roll call.  For
> > >> example, if we have a roll call of 21, then we'll need a minimum of 
11
> > >> binding votes participating.  Of that 11, we'd need 2/3 to be +1 to
> > pass,
> > >> so in that case 8 +1's.
> > >
> > >
> > > I guess we should visit this again afterwards, as this isn't what I
> > >> intended.
> > >
> > >
> > > I have little interest in changing any of the doc as written as
> reflected
> > > by my +1 vote. :)
> > >
> > > If you two could come to an agreement and articulate it / modify the
> wiki
> > > to reflect it, we can review as a community and vote again.
> > >
> > > Also, we should clarify the metrics by which the vote will pass which 
I
> > > didn't above. i.e. Simple Majority binding participants, Consensus 
from
> > > binding (no -1), etc. I'd advocate for simple majority since none of
> this
> > > is set in stone and at this point I believe we're bikeshedding against
> > > something that would be a non-issue assuming positive intent and
> > alignment
> > > between response to roll call and participation.
> > >
> > >
> > > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai  wrote:
> > >
> > >> +1 nb
> > >> 
> > >> From: Jon Haddad 
> > >> Sent: Wednesday, June 17, 2020 2:13 PM
> > >> To: dev@cassandra.apache.org
> > >> Subject: Re: [VOTE] Project governance wiki doc
> > >>
> > >> Yes, this is my understanding as well.
> > >>
> > >>
> > >> On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith <
> > >> bened...@apache.org>
> > >> wrote:
> > >>
> > >> > I personall

Re: [VOTE] Project governance wiki doc

2020-06-18 Thread Joshua McKenzie
I'm formally stopping the vote. Jon, please revise the wiki.

Good point about getting ourselves stuck into a corner we couldn't vote
ourselves back out of. That'd just be silly.

On Thu, Jun 18, 2020 at 12:19 PM Jon Haddad  wrote:

> > If you two could come to an agreement and articulate it / modify the
> wiki to reflect it, we can review as a community and vote again.
>
> Since you started the vote, it would be up to you to stop it so we can
> modify the doc.  I don't feel comfortable modifying a doc mid-vote, it's
> not fair to those that have voted, and I don't like introducing
> inconsistency into our voting.
>
> Since we're still governed by the Apache rules, this is a simple majority
> vote requiring a minimum 3 +1's.
>
> I am very concerned that if we raise the bar for voting too high, we will
> find ourselves in a position where we are unable to change the voting rules
> due to the bar being too high.  I may be in the minority here though.  I'm
> extremely curious if this process would have enough votes to pass the
> proposed voting guidelines, because if it doesn't, I don't see the point in
> adopting them.  Again, my opinion might not be shared by everyone else.
>
> I'm sticking with my -1 on the doc as-is.
>
> Thanks,
> Jon
>
> On Thu, Jun 18, 2020 at 8:17 AM Joshua McKenzie 
> wrote:
>
> > One follow up thought - if we're considering this vote simple majority,
> or
> > super majority of participants, it's passing and we can just follow up
> > w/revisions on a subsequent vote. I personally would prefer we go that
> > route; we all need to internalize that moving forward and incrementally
> > revising things is Safe and OK. :)
> >
> > ~Josh
> >
> > On Thu, Jun 18, 2020 at 10:00 AM Joshua McKenzie 
> > wrote:
> >
> > > So did you two come to an agreement? I must have misread:
> > >
> > > changing the minimum number of votes to be a simple
> > >> majority of the number of people participating in the roll call.  For
> > >> example, if we have a roll call of 21, then we'll need a minimum of 11
> > >> binding votes participating.  Of that 11, we'd need 2/3 to be +1 to
> > pass,
> > >> so in that case 8 +1's.
> > >
> > >
> > > I guess we should visit this again afterwards, as this isn't what I
> > >> intended.
> > >
> > >
> > > I have little interest in changing any of the doc as written as
> reflected
> > > by my +1 vote. :)
> > >
> > > If you two could come to an agreement and articulate it / modify the
> wiki
> > > to reflect it, we can review as a community and vote again.
> > >
> > > Also, we should clarify the metrics by which the vote will pass which I
> > > didn't above. i.e. Simple Majority binding participants, Consensus from
> > > binding (no -1), etc. I'd advocate for simple majority since none of
> this
> > > is set in stone and at this point I believe we're bikeshedding against
> > > something that would be a non-issue assuming positive intent and
> > alignment
> > > between response to roll call and participation.
> > >
> > >
> > > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai  wrote:
> > >
> > >> +1 nb
> > >> 
> > >> From: Jon Haddad 
> > >> Sent: Wednesday, June 17, 2020 2:13 PM
> > >> To: dev@cassandra.apache.org
> > >> Subject: Re: [VOTE] Project governance wiki doc
> > >>
> > >> Yes, this is my understanding as well.
> > >>
> > >>
> > >> On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith <
> > >> bened...@apache.org>
> > >> wrote:
> > >>
> > >> > I personally think we should not revisit the super-majority of votes
> > >> > decision, as that was settled already; simple-majority came a
> distant
> > >> > third.  Since this question doesn't really invalidate that
> decision, I
> > >> > think for forward progress it's better to simply address the vote
> > floor,
> > >> > but just my 2c.
> > >> >
> > >> > On 17/06/2020, 21:58, "Jon Haddad"  wrote:
> > >> >
> > >> > For what it's worth, I thought Benedict's suggestion was a
> pretty
> > >> > reasonable one and am in favor of it.
> > >> >
> > >> > On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie <
> > >> jmcken...@apache.org>
> > >> > wrote:
> 

Re: [VOTE] Project governance wiki doc

2020-06-18 Thread Jon Haddad
> If you two could come to an agreement and articulate it / modify the
wiki to reflect it, we can review as a community and vote again.

Since you started the vote, it would be up to you to stop it so we can
modify the doc.  I don't feel comfortable modifying a doc mid-vote, it's
not fair to those that have voted, and I don't like introducing
inconsistency into our voting.

Since we're still governed by the Apache rules, this is a simple majority
vote requiring a minimum 3 +1's.

I am very concerned that if we raise the bar for voting too high, we will
find ourselves in a position where we are unable to change the voting rules
due to the bar being too high.  I may be in the minority here though.  I'm
extremely curious if this process would have enough votes to pass the
proposed voting guidelines, because if it doesn't, I don't see the point in
adopting them.  Again, my opinion might not be shared by everyone else.

I'm sticking with my -1 on the doc as-is.

Thanks,
Jon

On Thu, Jun 18, 2020 at 8:17 AM Joshua McKenzie 
wrote:

> One follow up thought - if we're considering this vote simple majority, or
> super majority of participants, it's passing and we can just follow up
> w/revisions on a subsequent vote. I personally would prefer we go that
> route; we all need to internalize that moving forward and incrementally
> revising things is Safe and OK. :)
>
> ~Josh
>
> On Thu, Jun 18, 2020 at 10:00 AM Joshua McKenzie 
> wrote:
>
> > So did you two come to an agreement? I must have misread:
> >
> > changing the minimum number of votes to be a simple
> >> majority of the number of people participating in the roll call.  For
> >> example, if we have a roll call of 21, then we'll need a minimum of 11
> >> binding votes participating.  Of that 11, we'd need 2/3 to be +1 to
> pass,
> >> so in that case 8 +1's.
> >
> >
> > I guess we should visit this again afterwards, as this isn't what I
> >> intended.
> >
> >
> > I have little interest in changing any of the doc as written as reflected
> > by my +1 vote. :)
> >
> > If you two could come to an agreement and articulate it / modify the wiki
> > to reflect it, we can review as a community and vote again.
> >
> > Also, we should clarify the metrics by which the vote will pass which I
> > didn't above. i.e. Simple Majority binding participants, Consensus from
> > binding (no -1), etc. I'd advocate for simple majority since none of this
> > is set in stone and at this point I believe we're bikeshedding against
> > something that would be a non-issue assuming positive intent and
> alignment
> > between response to roll call and participation.
> >
> >
> > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai  wrote:
> >
> >> +1 nb
> >> 
> >> From: Jon Haddad 
> >> Sent: Wednesday, June 17, 2020 2:13 PM
> >> To: dev@cassandra.apache.org
> >> Subject: Re: [VOTE] Project governance wiki doc
> >>
> >> Yes, this is my understanding as well.
> >>
> >>
> >> On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith <
> >> bened...@apache.org>
> >> wrote:
> >>
> >> > I personally think we should not revisit the super-majority of votes
> >> > decision, as that was settled already; simple-majority came a distant
> >> > third.  Since this question doesn't really invalidate that decision, I
> >> > think for forward progress it's better to simply address the vote
> floor,
> >> > but just my 2c.
> >> >
> >> > On 17/06/2020, 21:58, "Jon Haddad"  wrote:
> >> >
> >> > For what it's worth, I thought Benedict's suggestion was a pretty
> >> > reasonable one and am in favor of it.
> >> >
> >> > On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie <
> >> jmcken...@apache.org>
> >> > wrote:
> >> >
> >> > > Race condition on that last one Benedict.
> >> > >
> >> > > What about using the quorum from roll call to simply define how
> >> many
> >> > +1's
> >> > > are needed to pass something? Simple majority of the roll call,
> >> > simple
> >> > > majority of total participants on specific vote and it passes?
> >> > >
> >> > > For example:
> >> > >
> >> > >- 33 pmc members
> >> > >- 16 roll call
> >> > >- 9 +1's required. If only participation is 9 vote with +1,
> >

Re: [VOTE] Project governance wiki doc

2020-06-18 Thread Joshua McKenzie
One follow up thought - if we're considering this vote simple majority, or
super majority of participants, it's passing and we can just follow up
w/revisions on a subsequent vote. I personally would prefer we go that
route; we all need to internalize that moving forward and incrementally
revising things is Safe and OK. :)

~Josh

On Thu, Jun 18, 2020 at 10:00 AM Joshua McKenzie 
wrote:

> So did you two come to an agreement? I must have misread:
>
> changing the minimum number of votes to be a simple
>> majority of the number of people participating in the roll call.  For
>> example, if we have a roll call of 21, then we'll need a minimum of 11
>> binding votes participating.  Of that 11, we'd need 2/3 to be +1 to pass,
>> so in that case 8 +1's.
>
>
> I guess we should visit this again afterwards, as this isn't what I
>> intended.
>
>
> I have little interest in changing any of the doc as written as reflected
> by my +1 vote. :)
>
> If you two could come to an agreement and articulate it / modify the wiki
> to reflect it, we can review as a community and vote again.
>
> Also, we should clarify the metrics by which the vote will pass which I
> didn't above. i.e. Simple Majority binding participants, Consensus from
> binding (no -1), etc. I'd advocate for simple majority since none of this
> is set in stone and at this point I believe we're bikeshedding against
> something that would be a non-issue assuming positive intent and alignment
> between response to roll call and participation.
>
>
> On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai  wrote:
>
>> +1 nb
>> ____
>> From: Jon Haddad 
>> Sent: Wednesday, June 17, 2020 2:13 PM
>> To: dev@cassandra.apache.org
>> Subject: Re: [VOTE] Project governance wiki doc
>>
>> Yes, this is my understanding as well.
>>
>>
>> On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith <
>> bened...@apache.org>
>> wrote:
>>
>> > I personally think we should not revisit the super-majority of votes
>> > decision, as that was settled already; simple-majority came a distant
>> > third.  Since this question doesn't really invalidate that decision, I
>> > think for forward progress it's better to simply address the vote floor,
>> > but just my 2c.
>> >
>> > On 17/06/2020, 21:58, "Jon Haddad"  wrote:
>> >
>> > For what it's worth, I thought Benedict's suggestion was a pretty
>> > reasonable one and am in favor of it.
>> >
>> > On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie <
>> jmcken...@apache.org>
>> > wrote:
>> >
>> > > Race condition on that last one Benedict.
>> > >
>> > > What about using the quorum from roll call to simply define how
>> many
>> > +1's
>> > > are needed to pass something? Simple majority of the roll call,
>> > simple
>> > > majority of total participants on specific vote and it passes?
>> > >
>> > > For example:
>> > >
>> > >- 33 pmc members
>> > >- 16 roll call
>> > >- 9 +1's required. If only participation is 9 vote with +1,
>> passes
>> > >- If 9 +1's and 10 -1's, does not pass
>> > >
>> > > That prevents the "abstain to keep vote invalid" while keeping
>> with
>> > the
>> > > lazy consensus spirit and requiring enough participation that a
>> vote
>> > should
>> > > reasonably be considered indicative. Does raise the bar a bit from
>> > "simple
>> > > majority of this many votes required" to "this many +1's
>> required",
>> > but
>> > > hopefully people responding to a roll call actually plan on
>> showing
>> > up. We
>> > > could also open votes with "this many +1's required to pass" which
>> > might
>> > > further encourage participation.
>> > >
>> > >
>> > > On Wed, Jun 17, 2020 at 2:24 PM Joshua McKenzie <
>> > jmcken...@apache.org>
>> > > wrote:
>> > >
>> > >> I don't see anybody advocating for the low watermark where it
>> > stands.
>> > >> I'm +1 on the "simple majority of roll call + supermajority of
>> that"
>> > >> revision, and no real harm in re-calling a vote today vs.
>> > yesterday; one
>> > >&g

Re: [VOTE] Project governance wiki doc

2020-06-18 Thread Joshua McKenzie
So did you two come to an agreement? I must have misread:

changing the minimum number of votes to be a simple
> majority of the number of people participating in the roll call.  For
> example, if we have a roll call of 21, then we'll need a minimum of 11
> binding votes participating.  Of that 11, we'd need 2/3 to be +1 to pass,
> so in that case 8 +1's.


I guess we should visit this again afterwards, as this isn't what I
> intended.


I have little interest in changing any of the doc as written as reflected
by my +1 vote. :)

If you two could come to an agreement and articulate it / modify the wiki
to reflect it, we can review as a community and vote again.

Also, we should clarify the metrics by which the vote will pass which I
didn't above. i.e. Simple Majority binding participants, Consensus from
binding (no -1), etc. I'd advocate for simple majority since none of this
is set in stone and at this point I believe we're bikeshedding against
something that would be a non-issue assuming positive intent and alignment
between response to roll call and participation.


On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai  wrote:

> +1 nb
> 
> From: Jon Haddad 
> Sent: Wednesday, June 17, 2020 2:13 PM
> To: dev@cassandra.apache.org
> Subject: Re: [VOTE] Project governance wiki doc
>
> Yes, this is my understanding as well.
>
>
> On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > I personally think we should not revisit the super-majority of votes
> > decision, as that was settled already; simple-majority came a distant
> > third.  Since this question doesn't really invalidate that decision, I
> > think for forward progress it's better to simply address the vote floor,
> > but just my 2c.
> >
> > On 17/06/2020, 21:58, "Jon Haddad"  wrote:
> >
> > For what it's worth, I thought Benedict's suggestion was a pretty
> > reasonable one and am in favor of it.
> >
> > On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie <
> jmcken...@apache.org>
> > wrote:
> >
> > > Race condition on that last one Benedict.
> > >
> > > What about using the quorum from roll call to simply define how
> many
> > +1's
> > > are needed to pass something? Simple majority of the roll call,
> > simple
> > > majority of total participants on specific vote and it passes?
> > >
> > > For example:
> > >
> > >- 33 pmc members
> > >- 16 roll call
> > >- 9 +1's required. If only participation is 9 vote with +1,
> passes
> > >- If 9 +1's and 10 -1's, does not pass
> > >
> > > That prevents the "abstain to keep vote invalid" while keeping with
> > the
> > > lazy consensus spirit and requiring enough participation that a
> vote
> > should
> > > reasonably be considered indicative. Does raise the bar a bit from
> > "simple
> > > majority of this many votes required" to "this many +1's required",
> > but
> > > hopefully people responding to a roll call actually plan on showing
> > up. We
> > > could also open votes with "this many +1's required to pass" which
> > might
> > > further encourage participation.
> > >
> > >
> > > On Wed, Jun 17, 2020 at 2:24 PM Joshua McKenzie <
> > jmcken...@apache.org>
> > > wrote:
> > >
> > >> I don't see anybody advocating for the low watermark where it
> > stands.
> > >> I'm +1 on the "simple majority of roll call + supermajority of
> that"
> > >> revision, and no real harm in re-calling a vote today vs.
> > yesterday; one
> > >> day delay to clean this up now doesn't seem too much an
> imposition.
> > >>
> > >> @Jonathan Haddad  - want to revise the wiki
> > article
> > >> and call a new vote?
> > >>
> > >>
> > >> On Wed, Jun 17, 2020 at 2:13 PM Jon Haddad 
> > wrote:
> > >>
> > >>> Sorry, I was a bit vague there.
> > >>>
> > >>> I'm in favor of changing the minimum number of votes to be a
> simple
> > >>> majority of the number of people participating in the roll call.
> > For
> > >>> example, if we have a roll call of 21, then we'll need a minimum
> > of 11
> > >>> binding votes participat

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Yifan Cai
+1 nb

From: Jon Haddad 
Sent: Wednesday, June 17, 2020 2:13 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Project governance wiki doc

Yes, this is my understanding as well.


On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith 
wrote:

> I personally think we should not revisit the super-majority of votes
> decision, as that was settled already; simple-majority came a distant
> third.  Since this question doesn't really invalidate that decision, I
> think for forward progress it's better to simply address the vote floor,
> but just my 2c.
>
> On 17/06/2020, 21:58, "Jon Haddad"  wrote:
>
> For what it's worth, I thought Benedict's suggestion was a pretty
> reasonable one and am in favor of it.
>
> On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie 
> wrote:
>
> > Race condition on that last one Benedict.
> >
> > What about using the quorum from roll call to simply define how many
> +1's
> > are needed to pass something? Simple majority of the roll call,
> simple
> > majority of total participants on specific vote and it passes?
> >
> > For example:
> >
> >- 33 pmc members
> >- 16 roll call
> >- 9 +1's required. If only participation is 9 vote with +1, passes
> >- If 9 +1's and 10 -1's, does not pass
> >
> > That prevents the "abstain to keep vote invalid" while keeping with
> the
> > lazy consensus spirit and requiring enough participation that a vote
> should
> > reasonably be considered indicative. Does raise the bar a bit from
> "simple
> > majority of this many votes required" to "this many +1's required",
> but
> > hopefully people responding to a roll call actually plan on showing
> up. We
> > could also open votes with "this many +1's required to pass" which
> might
> > further encourage participation.
> >
> >
> > On Wed, Jun 17, 2020 at 2:24 PM Joshua McKenzie <
> jmcken...@apache.org>
> > wrote:
> >
> >> I don't see anybody advocating for the low watermark where it
> stands.
> >> I'm +1 on the "simple majority of roll call + supermajority of that"
> >> revision, and no real harm in re-calling a vote today vs.
> yesterday; one
> >> day delay to clean this up now doesn't seem too much an imposition.
> >>
> >> @Jonathan Haddad  - want to revise the wiki
> article
> >> and call a new vote?
> >>
> >>
> >> On Wed, Jun 17, 2020 at 2:13 PM Jon Haddad 
> wrote:
> >>
> >>> Sorry, I was a bit vague there.
> >>>
> >>> I'm in favor of changing the minimum number of votes to be a simple
> >>> majority of the number of people participating in the roll call.
> For
> >>> example, if we have a roll call of 21, then we'll need a minimum
> of 11
> >>> binding votes participating.  Of that 11, we'd need 2/3 to be +1
> to pass,
> >>> so in that case 8 +1's.
> >>>
> >>> Regarding a new vote, I am personally in favor of that, yes.
> >>>
> >>>
> >>> On Wed, Jun 17, 2020 at 10:36 AM Brandon Williams <
> dri...@gmail.com>
> >>> wrote:
> >>>
> >>> > So with that (the -1), are you in favor of changing to simple
> majority
> >>> > (I am) and calling a new vote?
> >>> >
> >>> > On Wed, Jun 17, 2020 at 12:30 PM Jon Haddad 
> wrote:
> >>> > >
> >>> > > > I'm not concerned today, no, just musing and pointing out
> that
> >>> there
> >>> > are
> >>> > > easy ways to improve progress if we find there's an
> impediment.  I
> >>> don't
> >>> > > think it necessarily indicates bad intent to use voting rules
> as
> >>> > > formulated, either, for the record.
> >>> > >
> >>> > > Yeah, I didn't think you were serious about it being a
> problem, just
> >>> > wanted
> >>> > > to check.
> >>> > >
> >>> > > I'm changing my vote to a -1, in favor of a simple majority as
> the
> >>> low
> >>> > > watermark in vote participation (not approval).
> >>> > >
> &g

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Jon Haddad
Yes, this is my understanding as well.


On Wed, Jun 17, 2020 at 2:10 PM Benedict Elliott Smith 
wrote:

> I personally think we should not revisit the super-majority of votes
> decision, as that was settled already; simple-majority came a distant
> third.  Since this question doesn't really invalidate that decision, I
> think for forward progress it's better to simply address the vote floor,
> but just my 2c.
>
> On 17/06/2020, 21:58, "Jon Haddad"  wrote:
>
> For what it's worth, I thought Benedict's suggestion was a pretty
> reasonable one and am in favor of it.
>
> On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie 
> wrote:
>
> > Race condition on that last one Benedict.
> >
> > What about using the quorum from roll call to simply define how many
> +1's
> > are needed to pass something? Simple majority of the roll call,
> simple
> > majority of total participants on specific vote and it passes?
> >
> > For example:
> >
> >- 33 pmc members
> >- 16 roll call
> >- 9 +1's required. If only participation is 9 vote with +1, passes
> >- If 9 +1's and 10 -1's, does not pass
> >
> > That prevents the "abstain to keep vote invalid" while keeping with
> the
> > lazy consensus spirit and requiring enough participation that a vote
> should
> > reasonably be considered indicative. Does raise the bar a bit from
> "simple
> > majority of this many votes required" to "this many +1's required",
> but
> > hopefully people responding to a roll call actually plan on showing
> up. We
> > could also open votes with "this many +1's required to pass" which
> might
> > further encourage participation.
> >
> >
> > On Wed, Jun 17, 2020 at 2:24 PM Joshua McKenzie <
> jmcken...@apache.org>
> > wrote:
> >
> >> I don't see anybody advocating for the low watermark where it
> stands.
> >> I'm +1 on the "simple majority of roll call + supermajority of that"
> >> revision, and no real harm in re-calling a vote today vs.
> yesterday; one
> >> day delay to clean this up now doesn't seem too much an imposition.
> >>
> >> @Jonathan Haddad  - want to revise the wiki
> article
> >> and call a new vote?
> >>
> >>
> >> On Wed, Jun 17, 2020 at 2:13 PM Jon Haddad 
> wrote:
> >>
> >>> Sorry, I was a bit vague there.
> >>>
> >>> I'm in favor of changing the minimum number of votes to be a simple
> >>> majority of the number of people participating in the roll call.
> For
> >>> example, if we have a roll call of 21, then we'll need a minimum
> of 11
> >>> binding votes participating.  Of that 11, we'd need 2/3 to be +1
> to pass,
> >>> so in that case 8 +1's.
> >>>
> >>> Regarding a new vote, I am personally in favor of that, yes.
> >>>
> >>>
> >>> On Wed, Jun 17, 2020 at 10:36 AM Brandon Williams <
> dri...@gmail.com>
> >>> wrote:
> >>>
> >>> > So with that (the -1), are you in favor of changing to simple
> majority
> >>> > (I am) and calling a new vote?
> >>> >
> >>> > On Wed, Jun 17, 2020 at 12:30 PM Jon Haddad 
> wrote:
> >>> > >
> >>> > > > I'm not concerned today, no, just musing and pointing out
> that
> >>> there
> >>> > are
> >>> > > easy ways to improve progress if we find there's an
> impediment.  I
> >>> don't
> >>> > > think it necessarily indicates bad intent to use voting rules
> as
> >>> > > formulated, either, for the record.
> >>> > >
> >>> > > Yeah, I didn't think you were serious about it being a
> problem, just
> >>> > wanted
> >>> > > to check.
> >>> > >
> >>> > > I'm changing my vote to a -1, in favor of a simple majority as
> the
> >>> low
> >>> > > watermark in vote participation (not approval).
> >>> > >
> >>> > > On Wed, Jun 17, 2020 at 9:56 AM Benedict Elliott Smith <
> >>> > bened...@apache.org>
> >>> > > wrote:
> >>> > >
> >>> > > > I'm not concerned today, no, just musing and pointing out
> that
> >>> there
> >>> > are
> >>> > > > easy ways to improve progress if we find there's an
> impediment.  I
> >>> > don't
> >>> > > > think it necessarily indicates bad intent to use voting
> rules as
> >>> > > > formulated, either, for the record.
> >>> > > >
> >>> > > > I do think redefining the roll call low watermark would be a
> good
> >>> > thing to
> >>> > > > do though.  It was a mistake to bring this to a vote without
> >>> discussing
> >>> > > > it.  Sorry for my part in forgetting the comment hadn't been
> >>> responded
> >>> > to,
> >>> > > > and also for the initial issue with formulation - it stemmed
> from
> >>> > poorly
> >>> > > > specifying the use of super-majority in the private@
> indicative
> >>> votes
> >>> > > > (which didn't disambiguate between the two success metrics),
> and
> >>> > avoiding
> 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Jon Haddad
For what it's worth, I thought Benedict's suggestion was a pretty
reasonable one and am in favor of it.

On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie 
wrote:

> Race condition on that last one Benedict.
>
> What about using the quorum from roll call to simply define how many +1's
> are needed to pass something? Simple majority of the roll call, simple
> majority of total participants on specific vote and it passes?
>
> For example:
>
>- 33 pmc members
>- 16 roll call
>- 9 +1's required. If only participation is 9 vote with +1, passes
>- If 9 +1's and 10 -1's, does not pass
>
> That prevents the "abstain to keep vote invalid" while keeping with the
> lazy consensus spirit and requiring enough participation that a vote should
> reasonably be considered indicative. Does raise the bar a bit from "simple
> majority of this many votes required" to "this many +1's required", but
> hopefully people responding to a roll call actually plan on showing up. We
> could also open votes with "this many +1's required to pass" which might
> further encourage participation.
>
>
> On Wed, Jun 17, 2020 at 2:24 PM Joshua McKenzie 
> wrote:
>
>> I don't see anybody advocating for the low watermark where it stands.
>> I'm +1 on the "simple majority of roll call + supermajority of that"
>> revision, and no real harm in re-calling a vote today vs. yesterday; one
>> day delay to clean this up now doesn't seem too much an imposition.
>>
>> @Jonathan Haddad  - want to revise the wiki article
>> and call a new vote?
>>
>>
>> On Wed, Jun 17, 2020 at 2:13 PM Jon Haddad  wrote:
>>
>>> Sorry, I was a bit vague there.
>>>
>>> I'm in favor of changing the minimum number of votes to be a simple
>>> majority of the number of people participating in the roll call.  For
>>> example, if we have a roll call of 21, then we'll need a minimum of 11
>>> binding votes participating.  Of that 11, we'd need 2/3 to be +1 to pass,
>>> so in that case 8 +1's.
>>>
>>> Regarding a new vote, I am personally in favor of that, yes.
>>>
>>>
>>> On Wed, Jun 17, 2020 at 10:36 AM Brandon Williams 
>>> wrote:
>>>
>>> > So with that (the -1), are you in favor of changing to simple majority
>>> > (I am) and calling a new vote?
>>> >
>>> > On Wed, Jun 17, 2020 at 12:30 PM Jon Haddad  wrote:
>>> > >
>>> > > > I'm not concerned today, no, just musing and pointing out that
>>> there
>>> > are
>>> > > easy ways to improve progress if we find there's an impediment.  I
>>> don't
>>> > > think it necessarily indicates bad intent to use voting rules as
>>> > > formulated, either, for the record.
>>> > >
>>> > > Yeah, I didn't think you were serious about it being a problem, just
>>> > wanted
>>> > > to check.
>>> > >
>>> > > I'm changing my vote to a -1, in favor of a simple majority as the
>>> low
>>> > > watermark in vote participation (not approval).
>>> > >
>>> > > On Wed, Jun 17, 2020 at 9:56 AM Benedict Elliott Smith <
>>> > bened...@apache.org>
>>> > > wrote:
>>> > >
>>> > > > I'm not concerned today, no, just musing and pointing out that
>>> there
>>> > are
>>> > > > easy ways to improve progress if we find there's an impediment.  I
>>> > don't
>>> > > > think it necessarily indicates bad intent to use voting rules as
>>> > > > formulated, either, for the record.
>>> > > >
>>> > > > I do think redefining the roll call low watermark would be a good
>>> > thing to
>>> > > > do though.  It was a mistake to bring this to a vote without
>>> discussing
>>> > > > it.  Sorry for my part in forgetting the comment hadn't been
>>> responded
>>> > to,
>>> > > > and also for the initial issue with formulation - it stemmed from
>>> > poorly
>>> > > > specifying the use of super-majority in the private@ indicative
>>> votes
>>> > > > (which didn't disambiguate between the two success metrics), and
>>> > avoiding
>>> > > > disincentives to voting (requiring only a quorum of voters, rather
>>> > than a
>>> > > > quorum of positive voters, encourages abstention until the quorum
>>> is
>>> > > > reached).  The intention was always to get clarity from the
>>> community
>>> > > > before a formal vote.
>>> > > >
>>> > > > I don't personally mind if we do that as a modification once this
>>> vote
>>> > > > passes, or if we scrub the vote and try again.
>>> > > >
>>> > > >
>>> > > > On 17/06/2020, 17:35, "Jon Haddad"  wrote:
>>> > > >
>>> > > > >  On the document I raised this as an issue, and proposed
>>> > lowering the
>>> > > > "low watermark" to a simple majority of the electorate - since
>>> if
>>> > you
>>> > > > have
>>> > > > both a simple majority of the "active electorate", and a
>>> > > > super-majority of
>>> > > > all voters, I think you can consider that a strong consensus.
>>> > > >
>>> > > > Agree here.  I think a simple majority of the roll call + a
>>> super
>>> > > > majority
>>> > > > of votes sounds far more reasonable.
>>> > > >
>>> > > > > However it's worth noting that the active electorate is
>>> likely to
>>> > > > 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Joshua McKenzie
Race condition on that last one Benedict.

What about using the quorum from roll call to simply define how many +1's
are needed to pass something? Simple majority of the roll call, simple
majority of total participants on specific vote and it passes?

For example:

   - 33 pmc members
   - 16 roll call
   - 9 +1's required. If only participation is 9 vote with +1, passes
   - If 9 +1's and 10 -1's, does not pass

That prevents the "abstain to keep vote invalid" while keeping with the
lazy consensus spirit and requiring enough participation that a vote should
reasonably be considered indicative. Does raise the bar a bit from "simple
majority of this many votes required" to "this many +1's required", but
hopefully people responding to a roll call actually plan on showing up. We
could also open votes with "this many +1's required to pass" which might
further encourage participation.


On Wed, Jun 17, 2020 at 2:24 PM Joshua McKenzie 
wrote:

> I don't see anybody advocating for the low watermark where it stands.
> I'm +1 on the "simple majority of roll call + supermajority of that"
> revision, and no real harm in re-calling a vote today vs. yesterday; one
> day delay to clean this up now doesn't seem too much an imposition.
>
> @Jonathan Haddad  - want to revise the wiki article
> and call a new vote?
>
>
> On Wed, Jun 17, 2020 at 2:13 PM Jon Haddad  wrote:
>
>> Sorry, I was a bit vague there.
>>
>> I'm in favor of changing the minimum number of votes to be a simple
>> majority of the number of people participating in the roll call.  For
>> example, if we have a roll call of 21, then we'll need a minimum of 11
>> binding votes participating.  Of that 11, we'd need 2/3 to be +1 to pass,
>> so in that case 8 +1's.
>>
>> Regarding a new vote, I am personally in favor of that, yes.
>>
>>
>> On Wed, Jun 17, 2020 at 10:36 AM Brandon Williams 
>> wrote:
>>
>> > So with that (the -1), are you in favor of changing to simple majority
>> > (I am) and calling a new vote?
>> >
>> > On Wed, Jun 17, 2020 at 12:30 PM Jon Haddad  wrote:
>> > >
>> > > > I'm not concerned today, no, just musing and pointing out that there
>> > are
>> > > easy ways to improve progress if we find there's an impediment.  I
>> don't
>> > > think it necessarily indicates bad intent to use voting rules as
>> > > formulated, either, for the record.
>> > >
>> > > Yeah, I didn't think you were serious about it being a problem, just
>> > wanted
>> > > to check.
>> > >
>> > > I'm changing my vote to a -1, in favor of a simple majority as the low
>> > > watermark in vote participation (not approval).
>> > >
>> > > On Wed, Jun 17, 2020 at 9:56 AM Benedict Elliott Smith <
>> > bened...@apache.org>
>> > > wrote:
>> > >
>> > > > I'm not concerned today, no, just musing and pointing out that there
>> > are
>> > > > easy ways to improve progress if we find there's an impediment.  I
>> > don't
>> > > > think it necessarily indicates bad intent to use voting rules as
>> > > > formulated, either, for the record.
>> > > >
>> > > > I do think redefining the roll call low watermark would be a good
>> > thing to
>> > > > do though.  It was a mistake to bring this to a vote without
>> discussing
>> > > > it.  Sorry for my part in forgetting the comment hadn't been
>> responded
>> > to,
>> > > > and also for the initial issue with formulation - it stemmed from
>> > poorly
>> > > > specifying the use of super-majority in the private@ indicative
>> votes
>> > > > (which didn't disambiguate between the two success metrics), and
>> > avoiding
>> > > > disincentives to voting (requiring only a quorum of voters, rather
>> > than a
>> > > > quorum of positive voters, encourages abstention until the quorum is
>> > > > reached).  The intention was always to get clarity from the
>> community
>> > > > before a formal vote.
>> > > >
>> > > > I don't personally mind if we do that as a modification once this
>> vote
>> > > > passes, or if we scrub the vote and try again.
>> > > >
>> > > >
>> > > > On 17/06/2020, 17:35, "Jon Haddad"  wrote:
>> > > >
>> > > > >  On the document I raised this as an issue, and proposed
>> > lowering the
>> > > > "low watermark" to a simple majority of the electorate - since
>> if
>> > you
>> > > > have
>> > > > both a simple majority of the "active electorate", and a
>> > > > super-majority of
>> > > > all voters, I think you can consider that a strong consensus.
>> > > >
>> > > > Agree here.  I think a simple majority of the roll call + a
>> super
>> > > > majority
>> > > > of votes sounds far more reasonable.
>> > > >
>> > > > > However it's worth noting that the active electorate is
>> likely to
>> > > > undercount, since some people won't nominate themselves in the
>> roll
>> > > > call,
>> > > > but will still vote.  So it might not in practice be a
>> problem.  In
>> > > > fact it
>> > > > can be gamed by people who want to pass a motion that fails to
>> > reach
>> > > > the
>> > > > low watermark all 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Benedict Elliott Smith
I guess we should visit this again afterwards, as this isn't what I intended.

I intended that there would be a minimum of 11 votes _in favour_, not simply 11 
votes.  The reason being that otherwise, if you oppose something, you are 
incentivised _not to vote_ which is a disincentive to participation we should 
avoid.

As formulated today, we would need 14 votes _in favour_.


On 17/06/2020, 19:13, "Jon Haddad"  wrote:

Sorry, I was a bit vague there.

I'm in favor of changing the minimum number of votes to be a simple
majority of the number of people participating in the roll call.  For
example, if we have a roll call of 21, then we'll need a minimum of 11
binding votes participating.  Of that 11, we'd need 2/3 to be +1 to pass,
so in that case 8 +1's.

Regarding a new vote, I am personally in favor of that, yes.


On Wed, Jun 17, 2020 at 10:36 AM Brandon Williams  wrote:

> So with that (the -1), are you in favor of changing to simple majority
> (I am) and calling a new vote?
>
> On Wed, Jun 17, 2020 at 12:30 PM Jon Haddad  wrote:
> >
> > > I'm not concerned today, no, just musing and pointing out that there
> are
> > easy ways to improve progress if we find there's an impediment.  I don't
> > think it necessarily indicates bad intent to use voting rules as
> > formulated, either, for the record.
> >
> > Yeah, I didn't think you were serious about it being a problem, just
> wanted
> > to check.
> >
> > I'm changing my vote to a -1, in favor of a simple majority as the low
> > watermark in vote participation (not approval).
> >
> > On Wed, Jun 17, 2020 at 9:56 AM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> > > I'm not concerned today, no, just musing and pointing out that there
> are
> > > easy ways to improve progress if we find there's an impediment.  I
> don't
> > > think it necessarily indicates bad intent to use voting rules as
> > > formulated, either, for the record.
> > >
> > > I do think redefining the roll call low watermark would be a good
> thing to
> > > do though.  It was a mistake to bring this to a vote without 
discussing
> > > it.  Sorry for my part in forgetting the comment hadn't been responded
> to,
> > > and also for the initial issue with formulation - it stemmed from
> poorly
> > > specifying the use of super-majority in the private@ indicative votes
> > > (which didn't disambiguate between the two success metrics), and
> avoiding
> > > disincentives to voting (requiring only a quorum of voters, rather
> than a
> > > quorum of positive voters, encourages abstention until the quorum is
> > > reached).  The intention was always to get clarity from the community
> > > before a formal vote.
> > >
> > > I don't personally mind if we do that as a modification once this vote
> > > passes, or if we scrub the vote and try again.
> > >
> > >
> > > On 17/06/2020, 17:35, "Jon Haddad"  wrote:
> > >
> > > >  On the document I raised this as an issue, and proposed
> lowering the
> > > "low watermark" to a simple majority of the electorate - since if
> you
> > > have
> > > both a simple majority of the "active electorate", and a
> > > super-majority of
> > > all voters, I think you can consider that a strong consensus.
> > >
> > > Agree here.  I think a simple majority of the roll call + a super
> > > majority
> > > of votes sounds far more reasonable.
> > >
> > > > However it's worth noting that the active electorate is likely 
to
> > > undercount, since some people won't nominate themselves in the 
roll
> > > call,
> > > but will still vote.  So it might not in practice be a problem.  
In
> > > fact it
> > > can be gamed by people who want to pass a motion that fails to
> reach
> > > the
> > > low watermark all collaborating to not count their vote at the 
roll
> > > call.
> > > The only real advantage of the roll call is that it's simple to
> > > administer.
> > >
> > > Is this something you're concerned about, or just musing over?
> > >
> > >
> > > On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith <
> > > bened...@apache.org>
> > > wrote:
> > >
> > > > Sorry, I've been busy so not paid as close attention as I would
> like
> > > after
> > > > initial contributions to the formulation.  On the document I
> raised
> > > this as
> > > > an issue, and proposed lowering the "low watermark" to a simple
> > > majority of
> > > > the electorate - since if you have both a simple majority of the
> > > "active
> > > > electorate", and a super-majority of all voters, I think you can
> > > 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Joshua McKenzie
I don't see anybody advocating for the low watermark where it stands.
I'm +1 on the "simple majority of roll call + supermajority of that"
revision, and no real harm in re-calling a vote today vs. yesterday; one
day delay to clean this up now doesn't seem too much an imposition.

@Jonathan Haddad  - want to revise the wiki article and
call a new vote?


On Wed, Jun 17, 2020 at 2:13 PM Jon Haddad  wrote:

> Sorry, I was a bit vague there.
>
> I'm in favor of changing the minimum number of votes to be a simple
> majority of the number of people participating in the roll call.  For
> example, if we have a roll call of 21, then we'll need a minimum of 11
> binding votes participating.  Of that 11, we'd need 2/3 to be +1 to pass,
> so in that case 8 +1's.
>
> Regarding a new vote, I am personally in favor of that, yes.
>
>
> On Wed, Jun 17, 2020 at 10:36 AM Brandon Williams 
> wrote:
>
> > So with that (the -1), are you in favor of changing to simple majority
> > (I am) and calling a new vote?
> >
> > On Wed, Jun 17, 2020 at 12:30 PM Jon Haddad  wrote:
> > >
> > > > I'm not concerned today, no, just musing and pointing out that there
> > are
> > > easy ways to improve progress if we find there's an impediment.  I
> don't
> > > think it necessarily indicates bad intent to use voting rules as
> > > formulated, either, for the record.
> > >
> > > Yeah, I didn't think you were serious about it being a problem, just
> > wanted
> > > to check.
> > >
> > > I'm changing my vote to a -1, in favor of a simple majority as the low
> > > watermark in vote participation (not approval).
> > >
> > > On Wed, Jun 17, 2020 at 9:56 AM Benedict Elliott Smith <
> > bened...@apache.org>
> > > wrote:
> > >
> > > > I'm not concerned today, no, just musing and pointing out that there
> > are
> > > > easy ways to improve progress if we find there's an impediment.  I
> > don't
> > > > think it necessarily indicates bad intent to use voting rules as
> > > > formulated, either, for the record.
> > > >
> > > > I do think redefining the roll call low watermark would be a good
> > thing to
> > > > do though.  It was a mistake to bring this to a vote without
> discussing
> > > > it.  Sorry for my part in forgetting the comment hadn't been
> responded
> > to,
> > > > and also for the initial issue with formulation - it stemmed from
> > poorly
> > > > specifying the use of super-majority in the private@ indicative
> votes
> > > > (which didn't disambiguate between the two success metrics), and
> > avoiding
> > > > disincentives to voting (requiring only a quorum of voters, rather
> > than a
> > > > quorum of positive voters, encourages abstention until the quorum is
> > > > reached).  The intention was always to get clarity from the community
> > > > before a formal vote.
> > > >
> > > > I don't personally mind if we do that as a modification once this
> vote
> > > > passes, or if we scrub the vote and try again.
> > > >
> > > >
> > > > On 17/06/2020, 17:35, "Jon Haddad"  wrote:
> > > >
> > > > >  On the document I raised this as an issue, and proposed
> > lowering the
> > > > "low watermark" to a simple majority of the electorate - since if
> > you
> > > > have
> > > > both a simple majority of the "active electorate", and a
> > > > super-majority of
> > > > all voters, I think you can consider that a strong consensus.
> > > >
> > > > Agree here.  I think a simple majority of the roll call + a super
> > > > majority
> > > > of votes sounds far more reasonable.
> > > >
> > > > > However it's worth noting that the active electorate is likely
> to
> > > > undercount, since some people won't nominate themselves in the
> roll
> > > > call,
> > > > but will still vote.  So it might not in practice be a problem.
> In
> > > > fact it
> > > > can be gamed by people who want to pass a motion that fails to
> > reach
> > > > the
> > > > low watermark all collaborating to not count their vote at the
> roll
> > > > call.
> > > > The only real advantage of the roll call is that it's simple to
> > > > administer.
> > > >
> > > > Is this something you're concerned about, or just musing over?
> > > >
> > > >
> > > > On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith <
> > > > bened...@apache.org>
> > > > wrote:
> > > >
> > > > > Sorry, I've been busy so not paid as close attention as I would
> > like
> > > > after
> > > > > initial contributions to the formulation.  On the document I
> > raised
> > > > this as
> > > > > an issue, and proposed lowering the "low watermark" to a simple
> > > > majority of
> > > > > the electorate - since if you have both a simple majority of
> the
> > > > "active
> > > > > electorate", and a super-majority of all voters, I think you
> can
> > > > consider
> > > > > that a strong consensus.
> > > > >
> > > > > However it's worth noting that the active electorate is likely
> to
> > > > > undercount, since some people won't nominate 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Jon Haddad
Sorry, I was a bit vague there.

I'm in favor of changing the minimum number of votes to be a simple
majority of the number of people participating in the roll call.  For
example, if we have a roll call of 21, then we'll need a minimum of 11
binding votes participating.  Of that 11, we'd need 2/3 to be +1 to pass,
so in that case 8 +1's.

Regarding a new vote, I am personally in favor of that, yes.


On Wed, Jun 17, 2020 at 10:36 AM Brandon Williams  wrote:

> So with that (the -1), are you in favor of changing to simple majority
> (I am) and calling a new vote?
>
> On Wed, Jun 17, 2020 at 12:30 PM Jon Haddad  wrote:
> >
> > > I'm not concerned today, no, just musing and pointing out that there
> are
> > easy ways to improve progress if we find there's an impediment.  I don't
> > think it necessarily indicates bad intent to use voting rules as
> > formulated, either, for the record.
> >
> > Yeah, I didn't think you were serious about it being a problem, just
> wanted
> > to check.
> >
> > I'm changing my vote to a -1, in favor of a simple majority as the low
> > watermark in vote participation (not approval).
> >
> > On Wed, Jun 17, 2020 at 9:56 AM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> > > I'm not concerned today, no, just musing and pointing out that there
> are
> > > easy ways to improve progress if we find there's an impediment.  I
> don't
> > > think it necessarily indicates bad intent to use voting rules as
> > > formulated, either, for the record.
> > >
> > > I do think redefining the roll call low watermark would be a good
> thing to
> > > do though.  It was a mistake to bring this to a vote without discussing
> > > it.  Sorry for my part in forgetting the comment hadn't been responded
> to,
> > > and also for the initial issue with formulation - it stemmed from
> poorly
> > > specifying the use of super-majority in the private@ indicative votes
> > > (which didn't disambiguate between the two success metrics), and
> avoiding
> > > disincentives to voting (requiring only a quorum of voters, rather
> than a
> > > quorum of positive voters, encourages abstention until the quorum is
> > > reached).  The intention was always to get clarity from the community
> > > before a formal vote.
> > >
> > > I don't personally mind if we do that as a modification once this vote
> > > passes, or if we scrub the vote and try again.
> > >
> > >
> > > On 17/06/2020, 17:35, "Jon Haddad"  wrote:
> > >
> > > >  On the document I raised this as an issue, and proposed
> lowering the
> > > "low watermark" to a simple majority of the electorate - since if
> you
> > > have
> > > both a simple majority of the "active electorate", and a
> > > super-majority of
> > > all voters, I think you can consider that a strong consensus.
> > >
> > > Agree here.  I think a simple majority of the roll call + a super
> > > majority
> > > of votes sounds far more reasonable.
> > >
> > > > However it's worth noting that the active electorate is likely to
> > > undercount, since some people won't nominate themselves in the roll
> > > call,
> > > but will still vote.  So it might not in practice be a problem.  In
> > > fact it
> > > can be gamed by people who want to pass a motion that fails to
> reach
> > > the
> > > low watermark all collaborating to not count their vote at the roll
> > > call.
> > > The only real advantage of the roll call is that it's simple to
> > > administer.
> > >
> > > Is this something you're concerned about, or just musing over?
> > >
> > >
> > > On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith <
> > > bened...@apache.org>
> > > wrote:
> > >
> > > > Sorry, I've been busy so not paid as close attention as I would
> like
> > > after
> > > > initial contributions to the formulation.  On the document I
> raised
> > > this as
> > > > an issue, and proposed lowering the "low watermark" to a simple
> > > majority of
> > > > the electorate - since if you have both a simple majority of the
> > > "active
> > > > electorate", and a super-majority of all voters, I think you can
> > > consider
> > > > that a strong consensus.
> > > >
> > > > However it's worth noting that the active electorate is likely to
> > > > undercount, since some people won't nominate themselves in the
> roll
> > > call,
> > > > but will still vote.  So it might not in practice be a problem.
> In
> > > fact it
> > > > can be gamed by people who want to pass a motion that fails to
> reach
> > > the
> > > > low watermark all collaborating to not count their vote at the
> roll
> > > call.
> > > > The only real advantage of the roll call is that it's simple to
> > > administer.
> > > >
> > > > On 17/06/2020, 17:12, "Jon Haddad"  wrote:
> > > >
> > > > Looking at the doc again, I'm a bit concerned about this:
> > > >
> > > > > PMC roll call will be taken every 6 months. This is an
> 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Brandon Williams
So with that (the -1), are you in favor of changing to simple majority
(I am) and calling a new vote?

On Wed, Jun 17, 2020 at 12:30 PM Jon Haddad  wrote:
>
> > I'm not concerned today, no, just musing and pointing out that there are
> easy ways to improve progress if we find there's an impediment.  I don't
> think it necessarily indicates bad intent to use voting rules as
> formulated, either, for the record.
>
> Yeah, I didn't think you were serious about it being a problem, just wanted
> to check.
>
> I'm changing my vote to a -1, in favor of a simple majority as the low
> watermark in vote participation (not approval).
>
> On Wed, Jun 17, 2020 at 9:56 AM Benedict Elliott Smith 
> wrote:
>
> > I'm not concerned today, no, just musing and pointing out that there are
> > easy ways to improve progress if we find there's an impediment.  I don't
> > think it necessarily indicates bad intent to use voting rules as
> > formulated, either, for the record.
> >
> > I do think redefining the roll call low watermark would be a good thing to
> > do though.  It was a mistake to bring this to a vote without discussing
> > it.  Sorry for my part in forgetting the comment hadn't been responded to,
> > and also for the initial issue with formulation - it stemmed from poorly
> > specifying the use of super-majority in the private@ indicative votes
> > (which didn't disambiguate between the two success metrics), and avoiding
> > disincentives to voting (requiring only a quorum of voters, rather than a
> > quorum of positive voters, encourages abstention until the quorum is
> > reached).  The intention was always to get clarity from the community
> > before a formal vote.
> >
> > I don't personally mind if we do that as a modification once this vote
> > passes, or if we scrub the vote and try again.
> >
> >
> > On 17/06/2020, 17:35, "Jon Haddad"  wrote:
> >
> > >  On the document I raised this as an issue, and proposed lowering the
> > "low watermark" to a simple majority of the electorate - since if you
> > have
> > both a simple majority of the "active electorate", and a
> > super-majority of
> > all voters, I think you can consider that a strong consensus.
> >
> > Agree here.  I think a simple majority of the roll call + a super
> > majority
> > of votes sounds far more reasonable.
> >
> > > However it's worth noting that the active electorate is likely to
> > undercount, since some people won't nominate themselves in the roll
> > call,
> > but will still vote.  So it might not in practice be a problem.  In
> > fact it
> > can be gamed by people who want to pass a motion that fails to reach
> > the
> > low watermark all collaborating to not count their vote at the roll
> > call.
> > The only real advantage of the roll call is that it's simple to
> > administer.
> >
> > Is this something you're concerned about, or just musing over?
> >
> >
> > On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith <
> > bened...@apache.org>
> > wrote:
> >
> > > Sorry, I've been busy so not paid as close attention as I would like
> > after
> > > initial contributions to the formulation.  On the document I raised
> > this as
> > > an issue, and proposed lowering the "low watermark" to a simple
> > majority of
> > > the electorate - since if you have both a simple majority of the
> > "active
> > > electorate", and a super-majority of all voters, I think you can
> > consider
> > > that a strong consensus.
> > >
> > > However it's worth noting that the active electorate is likely to
> > > undercount, since some people won't nominate themselves in the roll
> > call,
> > > but will still vote.  So it might not in practice be a problem.  In
> > fact it
> > > can be gamed by people who want to pass a motion that fails to reach
> > the
> > > low watermark all collaborating to not count their vote at the roll
> > call.
> > > The only real advantage of the roll call is that it's simple to
> > administer.
> > >
> > > On 17/06/2020, 17:12, "Jon Haddad"  wrote:
> > >
> > > Looking at the doc again, I'm a bit concerned about this:
> > >
> > > > PMC roll call will be taken every 6 months. This is an email
> > to dev@
> > > w/the simple question to pmc members of “are you active on the
> > project
> > > and
> > > plan to participate in voting over the next 6 months?”. This is
> > > strictly an
> > > exercise to get quorum count and in no way restricts ability to
> > > participate
> > > during this time window. A super-majority of this count becomes
> > the
> > > low-watermark for votes in favour necessary to pass a motion,
> > with new
> > > PMC
> > > members added to the calculation.
> > >
> > > I imagine we'll see a lot of participation from folks in roll
> > call, and
> > > less when it comes to votes.  It's very easy to say 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Jon Haddad
> I'm not concerned today, no, just musing and pointing out that there are
easy ways to improve progress if we find there's an impediment.  I don't
think it necessarily indicates bad intent to use voting rules as
formulated, either, for the record.

Yeah, I didn't think you were serious about it being a problem, just wanted
to check.

I'm changing my vote to a -1, in favor of a simple majority as the low
watermark in vote participation (not approval).

On Wed, Jun 17, 2020 at 9:56 AM Benedict Elliott Smith 
wrote:

> I'm not concerned today, no, just musing and pointing out that there are
> easy ways to improve progress if we find there's an impediment.  I don't
> think it necessarily indicates bad intent to use voting rules as
> formulated, either, for the record.
>
> I do think redefining the roll call low watermark would be a good thing to
> do though.  It was a mistake to bring this to a vote without discussing
> it.  Sorry for my part in forgetting the comment hadn't been responded to,
> and also for the initial issue with formulation - it stemmed from poorly
> specifying the use of super-majority in the private@ indicative votes
> (which didn't disambiguate between the two success metrics), and avoiding
> disincentives to voting (requiring only a quorum of voters, rather than a
> quorum of positive voters, encourages abstention until the quorum is
> reached).  The intention was always to get clarity from the community
> before a formal vote.
>
> I don't personally mind if we do that as a modification once this vote
> passes, or if we scrub the vote and try again.
>
>
> On 17/06/2020, 17:35, "Jon Haddad"  wrote:
>
> >  On the document I raised this as an issue, and proposed lowering the
> "low watermark" to a simple majority of the electorate - since if you
> have
> both a simple majority of the "active electorate", and a
> super-majority of
> all voters, I think you can consider that a strong consensus.
>
> Agree here.  I think a simple majority of the roll call + a super
> majority
> of votes sounds far more reasonable.
>
> > However it's worth noting that the active electorate is likely to
> undercount, since some people won't nominate themselves in the roll
> call,
> but will still vote.  So it might not in practice be a problem.  In
> fact it
> can be gamed by people who want to pass a motion that fails to reach
> the
> low watermark all collaborating to not count their vote at the roll
> call.
> The only real advantage of the roll call is that it's simple to
> administer.
>
> Is this something you're concerned about, or just musing over?
>
>
> On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > Sorry, I've been busy so not paid as close attention as I would like
> after
> > initial contributions to the formulation.  On the document I raised
> this as
> > an issue, and proposed lowering the "low watermark" to a simple
> majority of
> > the electorate - since if you have both a simple majority of the
> "active
> > electorate", and a super-majority of all voters, I think you can
> consider
> > that a strong consensus.
> >
> > However it's worth noting that the active electorate is likely to
> > undercount, since some people won't nominate themselves in the roll
> call,
> > but will still vote.  So it might not in practice be a problem.  In
> fact it
> > can be gamed by people who want to pass a motion that fails to reach
> the
> > low watermark all collaborating to not count their vote at the roll
> call.
> > The only real advantage of the roll call is that it's simple to
> administer.
> >
> > On 17/06/2020, 17:12, "Jon Haddad"  wrote:
> >
> > Looking at the doc again, I'm a bit concerned about this:
> >
> > > PMC roll call will be taken every 6 months. This is an email
> to dev@
> > w/the simple question to pmc members of “are you active on the
> project
> > and
> > plan to participate in voting over the next 6 months?”. This is
> > strictly an
> > exercise to get quorum count and in no way restricts ability to
> > participate
> > during this time window. A super-majority of this count becomes
> the
> > low-watermark for votes in favour necessary to pass a motion,
> with new
> > PMC
> > members added to the calculation.
> >
> > I imagine we'll see a lot of participation from folks in roll
> call, and
> > less when it comes to votes.  It's very easy to say we'll do
> something,
> > it's another to follow through.  A glance at any active community
> > member's
> > review board (including my own) will confirm that.
> >
> > Just to provide a quick example with some rough numbers - it
> doesn't
> > seem
> > unreasonable to me that we'll get a roll call of 15-20 votes.
> On the
> > low
> 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Benedict Elliott Smith
I'm not concerned today, no, just musing and pointing out that there are easy 
ways to improve progress if we find there's an impediment.  I don't think it 
necessarily indicates bad intent to use voting rules as formulated, either, for 
the record.

I do think redefining the roll call low watermark would be a good thing to do 
though.  It was a mistake to bring this to a vote without discussing it.  Sorry 
for my part in forgetting the comment hadn't been responded to, and also for 
the initial issue with formulation - it stemmed from poorly specifying the use 
of super-majority in the private@ indicative votes (which didn't disambiguate 
between the two success metrics), and avoiding disincentives to voting 
(requiring only a quorum of voters, rather than a quorum of positive voters, 
encourages abstention until the quorum is reached).  The intention was always 
to get clarity from the community before a formal vote.

I don't personally mind if we do that as a modification once this vote passes, 
or if we scrub the vote and try again.


On 17/06/2020, 17:35, "Jon Haddad"  wrote:

>  On the document I raised this as an issue, and proposed lowering the
"low watermark" to a simple majority of the electorate - since if you have
both a simple majority of the "active electorate", and a super-majority of
all voters, I think you can consider that a strong consensus.

Agree here.  I think a simple majority of the roll call + a super majority
of votes sounds far more reasonable.

> However it's worth noting that the active electorate is likely to
undercount, since some people won't nominate themselves in the roll call,
but will still vote.  So it might not in practice be a problem.  In fact it
can be gamed by people who want to pass a motion that fails to reach the
low watermark all collaborating to not count their vote at the roll call.
The only real advantage of the roll call is that it's simple to administer.

Is this something you're concerned about, or just musing over?


On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith 
wrote:

> Sorry, I've been busy so not paid as close attention as I would like after
> initial contributions to the formulation.  On the document I raised this 
as
> an issue, and proposed lowering the "low watermark" to a simple majority 
of
> the electorate - since if you have both a simple majority of the "active
> electorate", and a super-majority of all voters, I think you can consider
> that a strong consensus.
>
> However it's worth noting that the active electorate is likely to
> undercount, since some people won't nominate themselves in the roll call,
> but will still vote.  So it might not in practice be a problem.  In fact 
it
> can be gamed by people who want to pass a motion that fails to reach the
> low watermark all collaborating to not count their vote at the roll call.
> The only real advantage of the roll call is that it's simple to 
administer.
>
> On 17/06/2020, 17:12, "Jon Haddad"  wrote:
>
> Looking at the doc again, I'm a bit concerned about this:
>
> > PMC roll call will be taken every 6 months. This is an email to dev@
> w/the simple question to pmc members of “are you active on the project
> and
> plan to participate in voting over the next 6 months?”. This is
> strictly an
> exercise to get quorum count and in no way restricts ability to
> participate
> during this time window. A super-majority of this count becomes the
> low-watermark for votes in favour necessary to pass a motion, with new
> PMC
> members added to the calculation.
>
> I imagine we'll see a lot of participation from folks in roll call, 
and
> less when it comes to votes.  It's very easy to say we'll do 
something,
> it's another to follow through.  A glance at any active community
> member's
> review board (including my own) will confirm that.
>
> Just to provide a quick example with some rough numbers - it doesn't
> seem
> unreasonable to me that we'll get a roll call of 15-20 votes.  On the
> low
> end of that, we'd need 10 votes to pass anything and on the high end,
> 14.
> On the high end a vote with 13 +1 and one -1 would fail.
>
> Just to be clear, I am 100% in favor of increased participation and a
> higher bar on voting, but I'd like to ensure we don't set the bar so
> high
> we can't get anything done.
>
> Anyone else share this sentiment?
>
> On Wed, Jun 17, 2020 at 8:37 AM David Capwell
> 
> wrote:
>
> > +1 nb
> >
> > Sent from my iPhone
> >
> > > On Jun 17, 2020, at 7:27 AM, Andrés de la Peña <
> a.penya.gar...@gmail.com>
> > wrote:
> > >
> > > +1 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Jon Haddad
>  On the document I raised this as an issue, and proposed lowering the
"low watermark" to a simple majority of the electorate - since if you have
both a simple majority of the "active electorate", and a super-majority of
all voters, I think you can consider that a strong consensus.

Agree here.  I think a simple majority of the roll call + a super majority
of votes sounds far more reasonable.

> However it's worth noting that the active electorate is likely to
undercount, since some people won't nominate themselves in the roll call,
but will still vote.  So it might not in practice be a problem.  In fact it
can be gamed by people who want to pass a motion that fails to reach the
low watermark all collaborating to not count their vote at the roll call.
The only real advantage of the roll call is that it's simple to administer.

Is this something you're concerned about, or just musing over?


On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith 
wrote:

> Sorry, I've been busy so not paid as close attention as I would like after
> initial contributions to the formulation.  On the document I raised this as
> an issue, and proposed lowering the "low watermark" to a simple majority of
> the electorate - since if you have both a simple majority of the "active
> electorate", and a super-majority of all voters, I think you can consider
> that a strong consensus.
>
> However it's worth noting that the active electorate is likely to
> undercount, since some people won't nominate themselves in the roll call,
> but will still vote.  So it might not in practice be a problem.  In fact it
> can be gamed by people who want to pass a motion that fails to reach the
> low watermark all collaborating to not count their vote at the roll call.
> The only real advantage of the roll call is that it's simple to administer.
>
> On 17/06/2020, 17:12, "Jon Haddad"  wrote:
>
> Looking at the doc again, I'm a bit concerned about this:
>
> > PMC roll call will be taken every 6 months. This is an email to dev@
> w/the simple question to pmc members of “are you active on the project
> and
> plan to participate in voting over the next 6 months?”. This is
> strictly an
> exercise to get quorum count and in no way restricts ability to
> participate
> during this time window. A super-majority of this count becomes the
> low-watermark for votes in favour necessary to pass a motion, with new
> PMC
> members added to the calculation.
>
> I imagine we'll see a lot of participation from folks in roll call, and
> less when it comes to votes.  It's very easy to say we'll do something,
> it's another to follow through.  A glance at any active community
> member's
> review board (including my own) will confirm that.
>
> Just to provide a quick example with some rough numbers - it doesn't
> seem
> unreasonable to me that we'll get a roll call of 15-20 votes.  On the
> low
> end of that, we'd need 10 votes to pass anything and on the high end,
> 14.
> On the high end a vote with 13 +1 and one -1 would fail.
>
> Just to be clear, I am 100% in favor of increased participation and a
> higher bar on voting, but I'd like to ensure we don't set the bar so
> high
> we can't get anything done.
>
> Anyone else share this sentiment?
>
> On Wed, Jun 17, 2020 at 8:37 AM David Capwell
> 
> wrote:
>
> > +1 nb
> >
> > Sent from my iPhone
> >
> > > On Jun 17, 2020, at 7:27 AM, Andrés de la Peña <
> a.penya.gar...@gmail.com>
> > wrote:
> > >
> > > +1 nb
> > >
> > >> On Wed, 17 Jun 2020 at 15:06, Sylvain Lebresne <
> lebre...@gmail.com>
> > wrote:
> > >>
> > >> +1 (binding)
> > >> --
> > >> Sylvain
> > >>
> > >>
> > >> On Wed, Jun 17, 2020 at 1:58 PM Benjamin Lerer <
> > >> benjamin.le...@datastax.com>
> > >> wrote:
> > >>
> > >>> +1 (binding)
> > >>>
> > >>> On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson <
> marc...@apache.org>
> > >>> wrote:
> > >>>
> >  +1
> > 
> > 
> >  On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com)
> wrote:
> > > +1 (binding)
> > >
> > >> On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> > >>
> > >> +1 nb
> > >>
> > >> On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> > >>
> > >>> +1 (binding)
> > >>>
> > >>> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
> > >>> wrote:
> > >>>
> >  Added unratified draft to the wiki here:
> > 
> > 
> > >>>
> > 
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > 
> >  I propose the following:
> > 
> >  1. We leave the vote open for 1 week (close at end of day
> > >> 6/23/20)
> > 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Jeremiah D Jordan
I think we need to assume positive intent here.  If someone says they will 
participate then we need to assume they are true to their word.  While the 
concerns are not un-founded, I think the doc as is gives a good starting point 
for trying this out without being too complicated.  If this turns out to be a 
problem in the future we can always re-visit the governance document.

-Jeremiah

> On Jun 17, 2020, at 11:21 AM, Benedict Elliott Smith  
> wrote:
> 
> Sorry, I've been busy so not paid as close attention as I would like after 
> initial contributions to the formulation.  On the document I raised this as 
> an issue, and proposed lowering the "low watermark" to a simple majority of 
> the electorate - since if you have both a simple majority of the "active 
> electorate", and a super-majority of all voters, I think you can consider 
> that a strong consensus.
> 
> However it's worth noting that the active electorate is likely to undercount, 
> since some people won't nominate themselves in the roll call, but will still 
> vote.  So it might not in practice be a problem.  In fact it can be gamed by 
> people who want to pass a motion that fails to reach the low watermark all 
> collaborating to not count their vote at the roll call.  The only real 
> advantage of the roll call is that it's simple to administer.
> 
> On 17/06/2020, 17:12, "Jon Haddad"  wrote:
> 
>Looking at the doc again, I'm a bit concerned about this:
> 
>> PMC roll call will be taken every 6 months. This is an email to dev@
>w/the simple question to pmc members of “are you active on the project and
>plan to participate in voting over the next 6 months?”. This is strictly an
>exercise to get quorum count and in no way restricts ability to participate
>during this time window. A super-majority of this count becomes the
>low-watermark for votes in favour necessary to pass a motion, with new PMC
>members added to the calculation.
> 
>I imagine we'll see a lot of participation from folks in roll call, and
>less when it comes to votes.  It's very easy to say we'll do something,
>it's another to follow through.  A glance at any active community member's
>review board (including my own) will confirm that.
> 
>Just to provide a quick example with some rough numbers - it doesn't seem
>unreasonable to me that we'll get a roll call of 15-20 votes.  On the low
>end of that, we'd need 10 votes to pass anything and on the high end, 14.
>On the high end a vote with 13 +1 and one -1 would fail.
> 
>Just to be clear, I am 100% in favor of increased participation and a
>higher bar on voting, but I'd like to ensure we don't set the bar so high
>we can't get anything done.
> 
>Anyone else share this sentiment?
> 
>On Wed, Jun 17, 2020 at 8:37 AM David Capwell 
>wrote:
> 
>> +1 nb
>> 
>> Sent from my iPhone
>> 
>>> On Jun 17, 2020, at 7:27 AM, Andrés de la Peña 
>> wrote:
>>> 
>>> +1 nb
>>> 
 On Wed, 17 Jun 2020 at 15:06, Sylvain Lebresne 
>> wrote:
 
 +1 (binding)
 --
 Sylvain
 
 
 On Wed, Jun 17, 2020 at 1:58 PM Benjamin Lerer <
 benjamin.le...@datastax.com>
 wrote:
 
> +1 (binding)
> 
> On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson 
> wrote:
> 
>> +1
>> 
>> 
>> On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
>>> +1 (binding)
>>> 
 On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
 
 +1 nb
 
 On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
 
> +1 (binding)
> 
> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
> wrote:
> 
>> Added unratified draft to the wiki here:
>> 
>> 
> 
>> 
> 
 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>> 
>> I propose the following:
>> 
>> 1. We leave the vote open for 1 week (close at end of day
 6/23/20)
>> unless there's a lot of feedback on the wiki we didn't get on
 gdoc
>> 2. pmc votes are considered binding
>> 3. committer and community votes are considered advisory /
>> non-binding
>> 
>> Any objections / revisions to the above?
>> 
>> Thanks!
>> 
>> ~Josh
>> 
> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
> 
 
>> 
>> 

Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Benedict Elliott Smith
Sorry, I've been busy so not paid as close attention as I would like after 
initial contributions to the formulation.  On the document I raised this as an 
issue, and proposed lowering the "low watermark" to a simple majority of the 
electorate - since if you have both a simple majority of the "active 
electorate", and a super-majority of all voters, I think you can consider that 
a strong consensus.

However it's worth noting that the active electorate is likely to undercount, 
since some people won't nominate themselves in the roll call, but will still 
vote.  So it might not in practice be a problem.  In fact it can be gamed by 
people who want to pass a motion that fails to reach the low watermark all 
collaborating to not count their vote at the roll call.  The only real 
advantage of the roll call is that it's simple to administer.

On 17/06/2020, 17:12, "Jon Haddad"  wrote:

Looking at the doc again, I'm a bit concerned about this:

> PMC roll call will be taken every 6 months. This is an email to dev@
w/the simple question to pmc members of “are you active on the project and
plan to participate in voting over the next 6 months?”. This is strictly an
exercise to get quorum count and in no way restricts ability to participate
during this time window. A super-majority of this count becomes the
low-watermark for votes in favour necessary to pass a motion, with new PMC
members added to the calculation.

I imagine we'll see a lot of participation from folks in roll call, and
less when it comes to votes.  It's very easy to say we'll do something,
it's another to follow through.  A glance at any active community member's
review board (including my own) will confirm that.

Just to provide a quick example with some rough numbers - it doesn't seem
unreasonable to me that we'll get a roll call of 15-20 votes.  On the low
end of that, we'd need 10 votes to pass anything and on the high end, 14.
On the high end a vote with 13 +1 and one -1 would fail.

Just to be clear, I am 100% in favor of increased participation and a
higher bar on voting, but I'd like to ensure we don't set the bar so high
we can't get anything done.

Anyone else share this sentiment?

On Wed, Jun 17, 2020 at 8:37 AM David Capwell 
wrote:

> +1 nb
>
> Sent from my iPhone
>
> > On Jun 17, 2020, at 7:27 AM, Andrés de la Peña 

> wrote:
> >
> > +1 nb
> >
> >> On Wed, 17 Jun 2020 at 15:06, Sylvain Lebresne 
> wrote:
> >>
> >> +1 (binding)
> >> --
> >> Sylvain
> >>
> >>
> >> On Wed, Jun 17, 2020 at 1:58 PM Benjamin Lerer <
> >> benjamin.le...@datastax.com>
> >> wrote:
> >>
> >>> +1 (binding)
> >>>
> >>> On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson 
> >>> wrote:
> >>>
>  +1
> 
> 
>  On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> > +1 (binding)
> >
> >> On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> >>
> >> +1 nb
> >>
> >> On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> >>
> >>> +1 (binding)
> >>>
> >>> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
> >>> wrote:
> >>>
>  Added unratified draft to the wiki here:
> 
> 
> >>>
> 
> >>>
> >>
> 
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> 
>  I propose the following:
> 
>  1. We leave the vote open for 1 week (close at end of day
> >> 6/23/20)
>  unless there's a lot of feedback on the wiki we didn't get on
> >> gdoc
>  2. pmc votes are considered binding
>  3. committer and community votes are considered advisory /
>  non-binding
> 
>  Any objections / revisions to the above?
> 
>  Thanks!
> 
>  ~Josh
> 
> >>>
> >
> >
> > 
-
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> 
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> >>>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>




Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Jon Haddad
Looking at the doc again, I'm a bit concerned about this:

> PMC roll call will be taken every 6 months. This is an email to dev@
w/the simple question to pmc members of “are you active on the project and
plan to participate in voting over the next 6 months?”. This is strictly an
exercise to get quorum count and in no way restricts ability to participate
during this time window. A super-majority of this count becomes the
low-watermark for votes in favour necessary to pass a motion, with new PMC
members added to the calculation.

I imagine we'll see a lot of participation from folks in roll call, and
less when it comes to votes.  It's very easy to say we'll do something,
it's another to follow through.  A glance at any active community member's
review board (including my own) will confirm that.

Just to provide a quick example with some rough numbers - it doesn't seem
unreasonable to me that we'll get a roll call of 15-20 votes.  On the low
end of that, we'd need 10 votes to pass anything and on the high end, 14.
On the high end a vote with 13 +1 and one -1 would fail.

Just to be clear, I am 100% in favor of increased participation and a
higher bar on voting, but I'd like to ensure we don't set the bar so high
we can't get anything done.

Anyone else share this sentiment?

On Wed, Jun 17, 2020 at 8:37 AM David Capwell 
wrote:

> +1 nb
>
> Sent from my iPhone
>
> > On Jun 17, 2020, at 7:27 AM, Andrés de la Peña 
> wrote:
> >
> > +1 nb
> >
> >> On Wed, 17 Jun 2020 at 15:06, Sylvain Lebresne 
> wrote:
> >>
> >> +1 (binding)
> >> --
> >> Sylvain
> >>
> >>
> >> On Wed, Jun 17, 2020 at 1:58 PM Benjamin Lerer <
> >> benjamin.le...@datastax.com>
> >> wrote:
> >>
> >>> +1 (binding)
> >>>
> >>> On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson 
> >>> wrote:
> >>>
>  +1
> 
> 
>  On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> > +1 (binding)
> >
> >> On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> >>
> >> +1 nb
> >>
> >> On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> >>
> >>> +1 (binding)
> >>>
> >>> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
> >>> wrote:
> >>>
>  Added unratified draft to the wiki here:
> 
> 
> >>>
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> 
>  I propose the following:
> 
>  1. We leave the vote open for 1 week (close at end of day
> >> 6/23/20)
>  unless there's a lot of feedback on the wiki we didn't get on
> >> gdoc
>  2. pmc votes are considered binding
>  3. committer and community votes are considered advisory /
>  non-binding
> 
>  Any objections / revisions to the above?
> 
>  Thanks!
> 
>  ~Josh
> 
> >>>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> 
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> >>>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc

2020-06-17 Thread David Capwell
+1 nb 

Sent from my iPhone

> On Jun 17, 2020, at 7:27 AM, Andrés de la Peña  
> wrote:
> 
> +1 nb
> 
>> On Wed, 17 Jun 2020 at 15:06, Sylvain Lebresne  wrote:
>> 
>> +1 (binding)
>> --
>> Sylvain
>> 
>> 
>> On Wed, Jun 17, 2020 at 1:58 PM Benjamin Lerer <
>> benjamin.le...@datastax.com>
>> wrote:
>> 
>>> +1 (binding)
>>> 
>>> On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson 
>>> wrote:
>>> 
 +1
 
 
 On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> +1 (binding)
> 
>> On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
>> 
>> +1 nb
>> 
>> On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
>> 
>>> +1 (binding)
>>> 
>>> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
>>> wrote:
>>> 
 Added unratified draft to the wiki here:
 
 
>>> 
 
>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
 
 I propose the following:
 
 1. We leave the vote open for 1 week (close at end of day
>> 6/23/20)
 unless there's a lot of feedback on the wiki we didn't get on
>> gdoc
 2. pmc votes are considered binding
 3. committer and community votes are considered advisory /
 non-binding
 
 Any objections / revisions to the above?
 
 Thanks!
 
 ~Josh
 
>>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Andrés de la Peña
+1 nb

On Wed, 17 Jun 2020 at 15:06, Sylvain Lebresne  wrote:

> +1 (binding)
> --
> Sylvain
>
>
> On Wed, Jun 17, 2020 at 1:58 PM Benjamin Lerer <
> benjamin.le...@datastax.com>
> wrote:
>
> > +1 (binding)
> >
> > On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson 
> > wrote:
> >
> > > +1
> > >
> > >
> > > On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> > > > +1 (binding)
> > > >
> > > > > On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> > > > >
> > > > > +1 nb
> > > > >
> > > > > On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> > > > >
> > > > >> +1 (binding)
> > > > >>
> > > > >> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
> > > > >> wrote:
> > > > >>
> > > > >>> Added unratified draft to the wiki here:
> > > > >>>
> > > > >>>
> > > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > > >>>
> > > > >>> I propose the following:
> > > > >>>
> > > > >>> 1. We leave the vote open for 1 week (close at end of day
> 6/23/20)
> > > > >>> unless there's a lot of feedback on the wiki we didn't get on
> gdoc
> > > > >>> 2. pmc votes are considered binding
> > > > >>> 3. committer and community votes are considered advisory /
> > > non-binding
> > > > >>>
> > > > >>> Any objections / revisions to the above?
> > > > >>>
> > > > >>> Thanks!
> > > > >>>
> > > > >>> ~Josh
> > > > >>>
> > > > >>
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>


Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Sylvain Lebresne
+1 (binding)
--
Sylvain


On Wed, Jun 17, 2020 at 1:58 PM Benjamin Lerer 
wrote:

> +1 (binding)
>
> On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson 
> wrote:
>
> > +1
> >
> >
> > On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> > > +1 (binding)
> > >
> > > > On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> > > >
> > > > +1 nb
> > > >
> > > > On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> > > >
> > > >> +1 (binding)
> > > >>
> > > >> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
> > > >> wrote:
> > > >>
> > > >>> Added unratified draft to the wiki here:
> > > >>>
> > > >>>
> > > >>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > >>>
> > > >>> I propose the following:
> > > >>>
> > > >>> 1. We leave the vote open for 1 week (close at end of day 6/23/20)
> > > >>> unless there's a lot of feedback on the wiki we didn't get on gdoc
> > > >>> 2. pmc votes are considered binding
> > > >>> 3. committer and community votes are considered advisory /
> > non-binding
> > > >>>
> > > >>> Any objections / revisions to the above?
> > > >>>
> > > >>> Thanks!
> > > >>>
> > > >>> ~Josh
> > > >>>
> > > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>


Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Benjamin Lerer
+1 (binding)

On Wed, Jun 17, 2020 at 12:49 PM Marcus Eriksson  wrote:

> +1
>
>
> On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> > +1 (binding)
> >
> > > On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> > >
> > > +1 nb
> > >
> > > On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> > >
> > >> +1 (binding)
> > >>
> > >> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie
> > >> wrote:
> > >>
> > >>> Added unratified draft to the wiki here:
> > >>>
> > >>>
> > >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > >>>
> > >>> I propose the following:
> > >>>
> > >>> 1. We leave the vote open for 1 week (close at end of day 6/23/20)
> > >>> unless there's a lot of feedback on the wiki we didn't get on gdoc
> > >>> 2. pmc votes are considered binding
> > >>> 3. committer and community votes are considered advisory /
> non-binding
> > >>>
> > >>> Any objections / revisions to the above?
> > >>>
> > >>> Thanks!
> > >>>
> > >>> ~Josh
> > >>>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Marcus Eriksson
+1


On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> +1 (binding)
> 
> > On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> >
> > +1 nb
> >
> > On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> >
> >> +1 (binding)
> >>
> >> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie 
> >> wrote:
> >>
> >>> Added unratified draft to the wiki here:
> >>>
> >>>
> >> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >>  
> >>>
> >>> I propose the following:
> >>>
> >>> 1. We leave the vote open for 1 week (close at end of day 6/23/20)
> >>> unless there's a lot of feedback on the wiki we didn't get on gdoc
> >>> 2. pmc votes are considered binding
> >>> 3. committer and community votes are considered advisory / non-binding
> >>>
> >>> Any objections / revisions to the above?
> >>>
> >>> Thanks!
> >>>
> >>> ~Josh
> >>>
> >>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Sam Tunnicliffe
+1 (binding)

> On 17 Jun 2020, at 09:11, Jorge Bay Gondra  wrote:
> 
> +1 nb
> 
> On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever  wrote:
> 
>> +1 (binding)
>> 
>> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie 
>> wrote:
>> 
>>> Added unratified draft to the wiki here:
>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>>> 
>>> I propose the following:
>>> 
>>>   1. We leave the vote open for 1 week (close at end of day 6/23/20)
>>>   unless there's a lot of feedback on the wiki we didn't get on gdoc
>>>   2. pmc votes are considered binding
>>>   3. committer and community votes are considered advisory / non-binding
>>> 
>>> Any objections / revisions to the above?
>>> 
>>> Thanks!
>>> 
>>> ~Josh
>>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc

2020-06-17 Thread Jorge Bay Gondra
+1 nb

On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever  wrote:

> +1 (binding)
>
> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie 
> wrote:
>
> > Added unratified draft to the wiki here:
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > I propose the following:
> >
> >1. We leave the vote open for 1 week (close at end of day 6/23/20)
> >unless there's a lot of feedback on the wiki we didn't get on gdoc
> >2. pmc votes are considered binding
> >3. committer and community votes are considered advisory / non-binding
> >
> > Any objections / revisions to the above?
> >
> > Thanks!
> >
> > ~Josh
> >
>


Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Mick Semb Wever
+1 (binding)

On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie  wrote:

> Added unratified draft to the wiki here:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> I propose the following:
>
>1. We leave the vote open for 1 week (close at end of day 6/23/20)
>unless there's a lot of feedback on the wiki we didn't get on gdoc
>2. pmc votes are considered binding
>3. committer and community votes are considered advisory / non-binding
>
> Any objections / revisions to the above?
>
> Thanks!
>
> ~Josh
>


Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Scott Andreas
+1 nb, thanks for everyone's work on this!


From: Jordan West 
Sent: Tuesday, June 16, 2020 8:09 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Project governance wiki doc

+1 nb

On Tue, Jun 16, 2020 at 5:45 PM Jake Luciani  wrote:

> +1
>
> On Tue, Jun 16, 2020 at 5:37 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > +1
> >
> > On 16/06/2020, 22:23, "Nate McCall"  wrote:
> >
> > +1 (binding)
> >
> > On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie <
> jmcken...@apache.org>
> > wrote:
> >
> > > Added unratified draft to the wiki here:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > >
> > > I propose the following:
> > >
> > >1. We leave the vote open for 1 week (close at end of day
> 6/23/20)
> > >unless there's a lot of feedback on the wiki we didn't get on
> gdoc
> > >2. pmc votes are considered binding
> > >3. committer and community votes are considered advisory /
> > non-binding
> > >
> > > Any objections / revisions to the above?
> > >
> > > Thanks!
> > >
> > > ~Josh
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> http://twitter.com/tjake
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Jordan West
+1 nb

On Tue, Jun 16, 2020 at 5:45 PM Jake Luciani  wrote:

> +1
>
> On Tue, Jun 16, 2020 at 5:37 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > +1
> >
> > On 16/06/2020, 22:23, "Nate McCall"  wrote:
> >
> > +1 (binding)
> >
> > On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie <
> jmcken...@apache.org>
> > wrote:
> >
> > > Added unratified draft to the wiki here:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > >
> > > I propose the following:
> > >
> > >1. We leave the vote open for 1 week (close at end of day
> 6/23/20)
> > >unless there's a lot of feedback on the wiki we didn't get on
> gdoc
> > >2. pmc votes are considered binding
> > >3. committer and community votes are considered advisory /
> > non-binding
> > >
> > > Any objections / revisions to the above?
> > >
> > > Thanks!
> > >
> > > ~Josh
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
> --
> http://twitter.com/tjake
>


Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Jake Luciani
+1

On Tue, Jun 16, 2020 at 5:37 PM Benedict Elliott Smith 
wrote:

> +1
>
> On 16/06/2020, 22:23, "Nate McCall"  wrote:
>
> +1 (binding)
>
> On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie 
> wrote:
>
> > Added unratified draft to the wiki here:
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > I propose the following:
> >
> >1. We leave the vote open for 1 week (close at end of day 6/23/20)
> >unless there's a lot of feedback on the wiki we didn't get on gdoc
> >2. pmc votes are considered binding
> >3. committer and community votes are considered advisory /
> non-binding
> >
> > Any objections / revisions to the above?
> >
> > Thanks!
> >
> > ~Josh
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
http://twitter.com/tjake


Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Benedict Elliott Smith
+1

On 16/06/2020, 22:23, "Nate McCall"  wrote:

+1 (binding)

On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie 
wrote:

> Added unratified draft to the wiki here:
>
> 
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> I propose the following:
>
>1. We leave the vote open for 1 week (close at end of day 6/23/20)
>unless there's a lot of feedback on the wiki we didn't get on gdoc
>2. pmc votes are considered binding
>3. committer and community votes are considered advisory / non-binding
>
> Any objections / revisions to the above?
>
> Thanks!
>
> ~Josh
>



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Nate McCall
+1 (binding)

On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie 
wrote:

> Added unratified draft to the wiki here:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> I propose the following:
>
>1. We leave the vote open for 1 week (close at end of day 6/23/20)
>unless there's a lot of feedback on the wiki we didn't get on gdoc
>2. pmc votes are considered binding
>3. committer and community votes are considered advisory / non-binding
>
> Any objections / revisions to the above?
>
> Thanks!
>
> ~Josh
>


Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Ekaterina Dimitrova
+1 (non-binding)

On Tue, 16 Jun 2020 at 13:24, Brandon Williams  wrote:

> +1 (binding)
>
> On Tue, Jun 16, 2020 at 11:19 AM Joshua McKenzie 
> wrote:
> >
> > Added unratified draft to the wiki here:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > I propose the following:
> >
> >1. We leave the vote open for 1 week (close at end of day 6/23/20)
> >unless there's a lot of feedback on the wiki we didn't get on gdoc
> >2. pmc votes are considered binding
> >3. committer and community votes are considered advisory / non-binding
> >
> > Any objections / revisions to the above?
> >
> > Thanks!
> >
> > ~Josh
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Joshua McKenzie
+1 (binding)

On Tue, Jun 16, 2020 at 1:24 PM Brandon Williams  wrote:

> +1 (binding)
>
> On Tue, Jun 16, 2020 at 11:19 AM Joshua McKenzie 
> wrote:
> >
> > Added unratified draft to the wiki here:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >
> > I propose the following:
> >
> >1. We leave the vote open for 1 week (close at end of day 6/23/20)
> >unless there's a lot of feedback on the wiki we didn't get on gdoc
> >2. pmc votes are considered binding
> >3. committer and community votes are considered advisory / non-binding
> >
> > Any objections / revisions to the above?
> >
> > Thanks!
> >
> > ~Josh
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Brandon Williams
+1 (binding)

On Tue, Jun 16, 2020 at 11:19 AM Joshua McKenzie  wrote:
>
> Added unratified draft to the wiki here:
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> I propose the following:
>
>1. We leave the vote open for 1 week (close at end of day 6/23/20)
>unless there's a lot of feedback on the wiki we didn't get on gdoc
>2. pmc votes are considered binding
>3. committer and community votes are considered advisory / non-binding
>
> Any objections / revisions to the above?
>
> Thanks!
>
> ~Josh

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Jon Haddad
+1 (binding)

On Tue, Jun 16, 2020 at 9:32 AM Jeremiah D Jordan 
wrote:

> +1 non-binding.
>
> Thanks for the work on this!
>
> > On Jun 16, 2020, at 11:31 AM, Jeff Jirsa  wrote:
> >
> > +1 (pmc, binding)
> >
> >
> > On Tue, Jun 16, 2020 at 9:19 AM Joshua McKenzie 
> > wrote:
> >
> >> Added unratified draft to the wiki here:
> >>
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >>
> >> I propose the following:
> >>
> >>   1. We leave the vote open for 1 week (close at end of day 6/23/20)
> >>   unless there's a lot of feedback on the wiki we didn't get on gdoc
> >>   2. pmc votes are considered binding
> >>   3. committer and community votes are considered advisory / non-binding
> >>
> >> Any objections / revisions to the above?
> >>
> >> Thanks!
> >>
> >> ~Josh
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Jeremiah D Jordan
+1 non-binding.

Thanks for the work on this!

> On Jun 16, 2020, at 11:31 AM, Jeff Jirsa  wrote:
> 
> +1 (pmc, binding)
> 
> 
> On Tue, Jun 16, 2020 at 9:19 AM Joshua McKenzie 
> wrote:
> 
>> Added unratified draft to the wiki here:
>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>> 
>> I propose the following:
>> 
>>   1. We leave the vote open for 1 week (close at end of day 6/23/20)
>>   unless there's a lot of feedback on the wiki we didn't get on gdoc
>>   2. pmc votes are considered binding
>>   3. committer and community votes are considered advisory / non-binding
>> 
>> Any objections / revisions to the above?
>> 
>> Thanks!
>> 
>> ~Josh
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Project governance wiki doc

2020-06-16 Thread Jeff Jirsa
+1 (pmc, binding)


On Tue, Jun 16, 2020 at 9:19 AM Joshua McKenzie 
wrote:

> Added unratified draft to the wiki here:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> I propose the following:
>
>1. We leave the vote open for 1 week (close at end of day 6/23/20)
>unless there's a lot of feedback on the wiki we didn't get on gdoc
>2. pmc votes are considered binding
>3. committer and community votes are considered advisory / non-binding
>
> Any objections / revisions to the above?
>
> Thanks!
>
> ~Josh
>


[VOTE] Project governance wiki doc

2020-06-16 Thread Joshua McKenzie
Added unratified draft to the wiki here:
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance

I propose the following:

   1. We leave the vote open for 1 week (close at end of day 6/23/20)
   unless there's a lot of feedback on the wiki we didn't get on gdoc
   2. pmc votes are considered binding
   3. committer and community votes are considered advisory / non-binding

Any objections / revisions to the above?

Thanks!

~Josh