You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Joan Touzet <wo...@apache.org> on 2019/03/05 20:19:41 UTC
[VOTE] Bylaws change: Establish a Qualified Lazy Majority vote type
for the RFC process (revised)
(Revised: The Reply-To field on the last email was incorrect. I am
also including the diff of the proposed changes to this email per
request.)
------------
PMC Members,
This is a VOTE to create or amend our official documents.
It establishes a new Qualified Lazy Majority voting type, and amends
the bylaws to use this new type for RFC votes only.
This vote depends on the RFC vote passing.
The git branch with the proposed further changes to the bylaws,
beyond the RFC process itself, is here:
https://github.com/apache/couchdb-www/compare/add-rfc...add-qualified-lazy-majority
Per our process, this vote occurs on the Main development list (dev@),
and requires a Lazy 2/3 majority, meaning it requires three binding +1
votes and twice as many binding +1 votes as binding -1 votes. Only PMC
Members can vote on this issue, and no veto is allowed.
This vote will run for one week, ending on 12 March 2019 23:59 UTC.
-Joan
---------------------------------------------------
diff --git a/bylaws.html b/bylaws.html
index 4aea136..7503b88 100644
--- a/bylaws.html
+++ b/bylaws.html
@@ -262,7 +262,7 @@
<h3 id="approval">3.4. Approval Models</h3>
-<p><strong>We use three different approval models for formal voting</strong>:
+<p><strong>We use four different approval models for formal voting</strong>:
<ul>
<li>RTC (see section 3.5)
@@ -273,6 +273,11 @@
<ul>
<li>Requires three binding +1 votes and more binding +1 votes than binding -1 votes
</ul>
+ <li>Qualified lazy majority
+ <ul>
+ <li>Requires three binding +1 votes and more binding +1 votes than binding -1 votes
+ <li>In addition, at least one binding +1 vote must be from an individual not directly affiliated with the proposer's employer (if applicable)
+ </ul>
<li>Lazy 2/3 majority
<ul>
<li>Requires three binding +1 votes and twice as many binding +1 votes as binding -1 votes
@@ -281,6 +286,8 @@
<p>RTC is only ever used in the context of a code review or a pull request, and does not require a separate vote thread. Each of the other approval models requires a vote thread.
+<p>Qualified lazy majority is only used for the <a href="#rfc">RFC process</a>.</p>
+
<p>A -1 vote is never called a veto except when using the RTC approval model. This is because a single -1 vote never has the power to block a vote outside of RTC.
<p>Which approval model to use is dictated by the table in section 3.6. This is project policy, and can be changed by amending this document.
@@ -316,7 +323,7 @@ The process is:
<ul>
<li>Start a [DISCUSS] thread on <a href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the developer mailing list</a>. Discuss your proposal in detail, including which modules/applications are affected, any HTTP API additions and deprecations, and security issues.</li>
<li>When there is consensus on the approach from the community, <a href="https://s.apache.org/CouchDB-RFC">complete the RFC template</a> and work through any final revisions to the document, with the support of the developer mailing list.</li>
- <li>Start the RFC <strong>vote</strong> on the developer mailing list. Hold the vote according to the <em>lazy majority process</em>: at least 3 +1 votes, and more binding +1 than binding -1 votes.</li>
+ <li>Start the RFC <strong>vote</strong> on the developer mailing list. Hold the vote according to the <em>qualified lazy majority process</em>: at least 3 +1 votes, more +1 than -1 votes, and at least one +1 vote must be from someone not directly affiliated with the proposer's employer.</li>
</ul>
<h3 id="api">3.7 API changes and deprecations</h3>
@@ -355,7 +362,7 @@ The process is:
<td>A decision on a specific proposal to alter CouchDB in a significant way.
<td><a href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main development list</a>
<td>No
- <td>Lazy majority
+ <td>Qualified lazy majority
<td>No
<td>Committers
<td>No
[RESULT] Bylaws change: Establish a Qualified Lazy Majority vote
type for the RFC process (revised)
Posted by Joan Touzet <wo...@apache.org>.
Dear Community,
The vote has now closed.
The results are:
+1 - 2 votes
+0 - 0 votes
-0 - 0 votes
-1 - 2 votes
The vote is FAILED.
Thanks,
Joan Touzet
Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority vote type for the RFC process (revised)
Posted by Jan Lehnardt <ma...@jan.io>.
For the reasons outlined in my previous email, and with the desire to show a way forward for other Apache projects (like we have done oh so many times), I'm in favour of adding this type of QLM vote and start by applying it to the RFC process:
+1
Cheers
Jan
—
> On 6. Mar 2019, at 10:41, Jan Lehnardt <ja...@apache.org> wrote:
>
> I’m not ready to vote just yet, but I’d like to chime in on the
> bad faith argument here.
>
> While I agree that an interpretation of reading the proposed
> policy as presuming bad faith, I don’t think that it is the
> *only* valid interpretation.
>
> The way I read this is more akin to the rules the web standards
> community set for itself, in where a new feature can only be
> put up for ratification if two independent implementations exist.
> One consequence here is that two teams with potentially varying
> implementation priorities come to an agreement about an API
> surface, leading to the benefit that that API surface most likely
> is robust enough and worth standardising.
>
> This process also does not assume bad faith, but has the neat
> side-effect of also eliminating a bad-faith player from getting
> their pet API standardised without much scrutiny.
>
> I believe a QLM vote type can be interpreted the same way: make
> sure two organisationally independent people have thought through
> a proposal to make it more robust. It has the neat side-effect of
> avoiding any bad-player shenanigans.
>
> In addition, I think we can make a case for this proposal just
> encoding existing practice. For example, I am personally more
> interested in the ease-of-use aspect of CouchDB, so when I
> propose a new feature, I will make sure to solicit feedback
> by at least one person from Cloudant to weigh in on whether my
> proposed change would work at the operational scale they are
> more experienced with. This is not me assuming Cloudant doesn’t
> care about ease-of-use (on the contrary!), but I’m looking to
> make my proposal more robust by relying on specific expertise
> of some of the group here. I can think of countless examples
> of this going in either direction between many subgroups of
> this dev community in the past.
>
> I want to close by emphasising that I don’t see an inkling of
> bad-faith participants in this project and I sleep well at
> night knowing I can assume good faith for everyone here.
>
>> On 6. Mar 2019, at 10:21, Garren Smith <ga...@apache.org> wrote:
>>
>> I'm -1 on this.
>> I agree with Bob on this, especially his point on:
>>
>> The Qualified Lazy Majority explicitly links an individual contributors
>> actions with their employee (where they have one) and therefore, in my
>> opinion, presumes bad faith.
>>
>>
>>
>>> On Wed, Mar 6, 2019 at 10:16 AM Joan Touzet <wo...@apache.org> wrote:
>>>
>>> I vote +1 for the following reason:
>>>
>>> The decision Robert proposes below (criteria, guidelines) can't be
>>> made reasonably if the PMC is already heavily slanted in that
>>> direction. By the time any such action might be taken, the PMC could
>>> already be corrupted in that way, meaning such a suggested set
>>> of criteria and a clear reason for calling it out is effectively
>>> moot.
>>>
>>> I feel this proposal strikes the best balance between pragmatism
>>> and idealism. It is largely a symbolic gesture, one taken to make
>>> the community feel better more than something that would actually
>>> prevent the small amount of collusion necessary (a single vote!)
>>> to step around it.
>>>
>>> It shows we care, and it shows we want to take a step towards being
>>> proactive against any perceived problem.
>>>
>>> I will not be crestfallen if this vote fails, but I will continue
>>> to advocate for its adoption.
>>>
>>> PMC members, please make your voices heard, one way or the other.
>>>
>>> -Joan
>>>
>>> ----- Original Message -----
>>>> From: "Robert Newson" <rn...@apache.org>
>>>> To: dev@couchdb.apache.org
>>>> Sent: Tuesday, 5 March, 2019 3:37:52 PM
>>>> Subject: Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority
>>> vote type for the RFC process (revised)
>>>>
>>>> -1 for the following reason:
>>>>
>>>> "https://apache.org/foundation/how-it-works.html#hats
>>>>
>>>> INDIVIDUALS COMPOSE THE ASF
>>>> All of the ASF including the board, the other officers, the
>>>> committers, and the members, are participating as individuals. That
>>>> is one strength of the ASF, affiliations do not cloud the personal
>>>> contributions."
>>>>
>>>> The Qualified Lazy Majority explicitly links an individual
>>>> contributors actions with their employee (where they have one) and
>>>> therefore, in my opinion, presumes bad faith.
>>>>
>>>> I agree that some ASF projects appear to have been co-opted by a
>>>> single company, that some people may believe this is true of CouchDB
>>>> and this deserves a response.
>>>>
>>>> I would vote _for_ a bylaw change that addressed this head-on. For
>>>> example, if we established a remedy for when this occurs (temporary
>>>> or permanent suspension, for example) or a definition of what we
>>>> would consider an occurrence. Obviously that is a hard problem and
>>>> presumably the reason it hasn't yet been proposed.
>>>>
>>>> B.
>>>>
>>>> --
>>>> Robert Samuel Newson
>>>> rnewson@apache.org
>>>>
>>>>> On Tue, 5 Mar 2019, at 20:29, Joan Touzet wrote:
>>>>> (Revised: The Reply-To field on the last email was incorrect. I am
>>>>> also including the diff of the proposed changes to this email per
>>>>> request.)
>>>>>
>>>>> ------------
>>>>>
>>>>> PMC Members,
>>>>>
>>>>> This is a VOTE to create or amend our official documents.
>>>>>
>>>>> It establishes a new Qualified Lazy Majority voting type, and
>>>>> amends
>>>>> the bylaws to use this new type for RFC votes only.
>>>>>
>>>>> This vote depends on the RFC vote passing.
>>>>>
>>>>> The git branch with the proposed further changes to the bylaws,
>>>>> beyond the RFC process itself, is here:
>>>>>
>>>>>
>>>>>
>>> https://github.com/apache/couchdb-www/compare/add-rfc...add-qualified-lazy-majority
>>>>>
>>>>> Per our process, this vote occurs on the Main development list
>>>>> (dev@),
>>>>> and requires a Lazy 2/3 majority, meaning it requires three binding
>>>>> +1
>>>>> votes and twice as many binding +1 votes as binding -1 votes. Only
>>>>> PMC
>>>>> Members can vote on this issue, and no veto is allowed.
>>>>>
>>>>> This vote will run for one week, ending on 12 March 2019 23:59 UTC.
>>>>>
>>>>> -Joan
>>>>>
>>>>> ---------------------------------------------------
>>>>>
>>>>> diff --git a/bylaws.html b/bylaws.html
>>>>> index 4aea136..7503b88 100644
>>>>> --- a/bylaws.html
>>>>> +++ b/bylaws.html
>>>>> @@ -262,7 +262,7 @@
>>>>>
>>>>> <h3 id="approval">3.4. Approval Models</h3>
>>>>>
>>>>> -<p><strong>We use three different approval models for formal
>>>>> voting</strong>:
>>>>> +<p><strong>We use four different approval models for formal
>>>>> voting</strong>:
>>>>>
>>>>> <ul>
>>>>> <li>RTC (see section 3.5)
>>>>> @@ -273,6 +273,11 @@
>>>>> <ul>
>>>>> <li>Requires three binding +1 votes and more binding +1
>>>>> votes
>>>>> than binding -1 votes
>>>>> </ul>
>>>>> + <li>Qualified lazy majority
>>>>> + <ul>
>>>>> + <li>Requires three binding +1 votes and more binding +1
>>>>> votes
>>>>> than binding -1 votes
>>>>> + <li>In addition, at least one binding +1 vote must be from
>>>>> an
>>>>> individual not directly affiliated with the proposer's employer (if
>>>>> applicable)
>>>>> + </ul>
>>>>> <li>Lazy 2/3 majority
>>>>> <ul>
>>>>> <li>Requires three binding +1 votes and twice as many
>>>>> binding
>>>>> +1 votes as binding -1 votes
>>>>> @@ -281,6 +286,8 @@
>>>>>
>>>>> <p>RTC is only ever used in the context of a code review or a pull
>>>>> request, and does not require a separate vote thread. Each of the
>>>>> other
>>>>> approval models requires a vote thread.
>>>>>
>>>>> +<p>Qualified lazy majority is only used for the <a href="#rfc">RFC
>>>>> process</a>.</p>
>>>>> +
>>>>> <p>A -1 vote is never called a veto except when using the RTC
>>>>> approval
>>>>> model. This is because a single -1 vote never has the power to
>>>>> block a
>>>>> vote outside of RTC.
>>>>>
>>>>> <p>Which approval model to use is dictated by the table in section
>>>>> 3.6. This is project policy, and can be changed by amending this
>>>>> document.
>>>>> @@ -316,7 +323,7 @@ The process is:
>>>>> <ul>
>>>>> <li>Start a [DISCUSS] thread on <a
>>>>> href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the
>>>>> developer mailing list</a>. Discuss your proposal in detail,
>>>>> including
>>>>> which modules/applications are affected, any HTTP API additions and
>>>>> deprecations, and security issues.</li>
>>>>> <li>When there is consensus on the approach from the
>>>>> community, <a
>>>>> href="https://s.apache.org/CouchDB-RFC">complete the RFC
>>>>> template</a>
>>>>> and work through any final revisions to the document, with the
>>>>> support
>>>>> of the developer mailing list.</li>
>>>>> - <li>Start the RFC <strong>vote</strong> on the developer
>>>>> mailing
>>>>> list. Hold the vote according to the <em>lazy majority
>>>>> process</em>: at
>>>>> least 3 +1 votes, and more binding +1 than binding -1 votes.</li>
>>>>> + <li>Start the RFC <strong>vote</strong> on the developer
>>>>> mailing
>>>>> list. Hold the vote according to the <em>qualified lazy majority
>>>>> process</em>: at least 3 +1 votes, more +1 than -1 votes, and at
>>>>> least
>>>>> one +1 vote must be from someone not directly affiliated with the
>>>>> proposer's employer.</li>
>>>>> </ul>
>>>>>
>>>>> <h3 id="api">3.7 API changes and deprecations</h3>
>>>>> @@ -355,7 +362,7 @@ The process is:
>>>>> <td>A decision on a specific proposal to alter CouchDB in a
>>>>> significant way.
>>>>> <td><a
>>>>> href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main
>>>>> development list</a>
>>>>> <td>No
>>>>> - <td>Lazy majority
>>>>> + <td>Qualified lazy majority
>>>>> <td>No
>>>>> <td>Committers
>>>>> <td>No
>>>>>
>>>>
>>>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority vote
type for the RFC process (revised)
Posted by Jan Lehnardt <ja...@apache.org>.
I’m not ready to vote just yet, but I’d like to chime in on the
bad faith argument here.
While I agree that an interpretation of reading the proposed
policy as presuming bad faith, I don’t think that it is the
*only* valid interpretation.
The way I read this is more akin to the rules the web standards
community set for itself, in where a new feature can only be
put up for ratification if two independent implementations exist.
One consequence here is that two teams with potentially varying
implementation priorities come to an agreement about an API
surface, leading to the benefit that that API surface most likely
is robust enough and worth standardising.
This process also does not assume bad faith, but has the neat
side-effect of also eliminating a bad-faith player from getting
their pet API standardised without much scrutiny.
I believe a QLM vote type can be interpreted the same way: make
sure two organisationally independent people have thought through
a proposal to make it more robust. It has the neat side-effect of
avoiding any bad-player shenanigans.
In addition, I think we can make a case for this proposal just
encoding existing practice. For example, I am personally more
interested in the ease-of-use aspect of CouchDB, so when I
propose a new feature, I will make sure to solicit feedback
by at least one person from Cloudant to weigh in on whether my
proposed change would work at the operational scale they are
more experienced with. This is not me assuming Cloudant doesn’t
care about ease-of-use (on the contrary!), but I’m looking to
make my proposal more robust by relying on specific expertise
of some of the group here. I can think of countless examples
of this going in either direction between many subgroups of
this dev community in the past.
I want to close by emphasising that I don’t see an inkling of
bad-faith participants in this project and I sleep well at
night knowing I can assume good faith for everyone here.
> On 6. Mar 2019, at 10:21, Garren Smith <ga...@apache.org> wrote:
>
> I'm -1 on this.
> I agree with Bob on this, especially his point on:
>
> The Qualified Lazy Majority explicitly links an individual contributors
> actions with their employee (where they have one) and therefore, in my
> opinion, presumes bad faith.
>
>
>
> On Wed, Mar 6, 2019 at 10:16 AM Joan Touzet <wo...@apache.org> wrote:
>
>> I vote +1 for the following reason:
>>
>> The decision Robert proposes below (criteria, guidelines) can't be
>> made reasonably if the PMC is already heavily slanted in that
>> direction. By the time any such action might be taken, the PMC could
>> already be corrupted in that way, meaning such a suggested set
>> of criteria and a clear reason for calling it out is effectively
>> moot.
>>
>> I feel this proposal strikes the best balance between pragmatism
>> and idealism. It is largely a symbolic gesture, one taken to make
>> the community feel better more than something that would actually
>> prevent the small amount of collusion necessary (a single vote!)
>> to step around it.
>>
>> It shows we care, and it shows we want to take a step towards being
>> proactive against any perceived problem.
>>
>> I will not be crestfallen if this vote fails, but I will continue
>> to advocate for its adoption.
>>
>> PMC members, please make your voices heard, one way or the other.
>>
>> -Joan
>>
>> ----- Original Message -----
>>> From: "Robert Newson" <rn...@apache.org>
>>> To: dev@couchdb.apache.org
>>> Sent: Tuesday, 5 March, 2019 3:37:52 PM
>>> Subject: Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority
>> vote type for the RFC process (revised)
>>>
>>> -1 for the following reason:
>>>
>>> "https://apache.org/foundation/how-it-works.html#hats
>>>
>>> INDIVIDUALS COMPOSE THE ASF
>>> All of the ASF including the board, the other officers, the
>>> committers, and the members, are participating as individuals. That
>>> is one strength of the ASF, affiliations do not cloud the personal
>>> contributions."
>>>
>>> The Qualified Lazy Majority explicitly links an individual
>>> contributors actions with their employee (where they have one) and
>>> therefore, in my opinion, presumes bad faith.
>>>
>>> I agree that some ASF projects appear to have been co-opted by a
>>> single company, that some people may believe this is true of CouchDB
>>> and this deserves a response.
>>>
>>> I would vote _for_ a bylaw change that addressed this head-on. For
>>> example, if we established a remedy for when this occurs (temporary
>>> or permanent suspension, for example) or a definition of what we
>>> would consider an occurrence. Obviously that is a hard problem and
>>> presumably the reason it hasn't yet been proposed.
>>>
>>> B.
>>>
>>> --
>>> Robert Samuel Newson
>>> rnewson@apache.org
>>>
>>> On Tue, 5 Mar 2019, at 20:29, Joan Touzet wrote:
>>>> (Revised: The Reply-To field on the last email was incorrect. I am
>>>> also including the diff of the proposed changes to this email per
>>>> request.)
>>>>
>>>> ------------
>>>>
>>>> PMC Members,
>>>>
>>>> This is a VOTE to create or amend our official documents.
>>>>
>>>> It establishes a new Qualified Lazy Majority voting type, and
>>>> amends
>>>> the bylaws to use this new type for RFC votes only.
>>>>
>>>> This vote depends on the RFC vote passing.
>>>>
>>>> The git branch with the proposed further changes to the bylaws,
>>>> beyond the RFC process itself, is here:
>>>>
>>>>
>>>>
>> https://github.com/apache/couchdb-www/compare/add-rfc...add-qualified-lazy-majority
>>>>
>>>> Per our process, this vote occurs on the Main development list
>>>> (dev@),
>>>> and requires a Lazy 2/3 majority, meaning it requires three binding
>>>> +1
>>>> votes and twice as many binding +1 votes as binding -1 votes. Only
>>>> PMC
>>>> Members can vote on this issue, and no veto is allowed.
>>>>
>>>> This vote will run for one week, ending on 12 March 2019 23:59 UTC.
>>>>
>>>> -Joan
>>>>
>>>> ---------------------------------------------------
>>>>
>>>> diff --git a/bylaws.html b/bylaws.html
>>>> index 4aea136..7503b88 100644
>>>> --- a/bylaws.html
>>>> +++ b/bylaws.html
>>>> @@ -262,7 +262,7 @@
>>>>
>>>> <h3 id="approval">3.4. Approval Models</h3>
>>>>
>>>> -<p><strong>We use three different approval models for formal
>>>> voting</strong>:
>>>> +<p><strong>We use four different approval models for formal
>>>> voting</strong>:
>>>>
>>>> <ul>
>>>> <li>RTC (see section 3.5)
>>>> @@ -273,6 +273,11 @@
>>>> <ul>
>>>> <li>Requires three binding +1 votes and more binding +1
>>>> votes
>>>> than binding -1 votes
>>>> </ul>
>>>> + <li>Qualified lazy majority
>>>> + <ul>
>>>> + <li>Requires three binding +1 votes and more binding +1
>>>> votes
>>>> than binding -1 votes
>>>> + <li>In addition, at least one binding +1 vote must be from
>>>> an
>>>> individual not directly affiliated with the proposer's employer (if
>>>> applicable)
>>>> + </ul>
>>>> <li>Lazy 2/3 majority
>>>> <ul>
>>>> <li>Requires three binding +1 votes and twice as many
>>>> binding
>>>> +1 votes as binding -1 votes
>>>> @@ -281,6 +286,8 @@
>>>>
>>>> <p>RTC is only ever used in the context of a code review or a pull
>>>> request, and does not require a separate vote thread. Each of the
>>>> other
>>>> approval models requires a vote thread.
>>>>
>>>> +<p>Qualified lazy majority is only used for the <a href="#rfc">RFC
>>>> process</a>.</p>
>>>> +
>>>> <p>A -1 vote is never called a veto except when using the RTC
>>>> approval
>>>> model. This is because a single -1 vote never has the power to
>>>> block a
>>>> vote outside of RTC.
>>>>
>>>> <p>Which approval model to use is dictated by the table in section
>>>> 3.6. This is project policy, and can be changed by amending this
>>>> document.
>>>> @@ -316,7 +323,7 @@ The process is:
>>>> <ul>
>>>> <li>Start a [DISCUSS] thread on <a
>>>> href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the
>>>> developer mailing list</a>. Discuss your proposal in detail,
>>>> including
>>>> which modules/applications are affected, any HTTP API additions and
>>>> deprecations, and security issues.</li>
>>>> <li>When there is consensus on the approach from the
>>>> community, <a
>>>> href="https://s.apache.org/CouchDB-RFC">complete the RFC
>>>> template</a>
>>>> and work through any final revisions to the document, with the
>>>> support
>>>> of the developer mailing list.</li>
>>>> - <li>Start the RFC <strong>vote</strong> on the developer
>>>> mailing
>>>> list. Hold the vote according to the <em>lazy majority
>>>> process</em>: at
>>>> least 3 +1 votes, and more binding +1 than binding -1 votes.</li>
>>>> + <li>Start the RFC <strong>vote</strong> on the developer
>>>> mailing
>>>> list. Hold the vote according to the <em>qualified lazy majority
>>>> process</em>: at least 3 +1 votes, more +1 than -1 votes, and at
>>>> least
>>>> one +1 vote must be from someone not directly affiliated with the
>>>> proposer's employer.</li>
>>>> </ul>
>>>>
>>>> <h3 id="api">3.7 API changes and deprecations</h3>
>>>> @@ -355,7 +362,7 @@ The process is:
>>>> <td>A decision on a specific proposal to alter CouchDB in a
>>>> significant way.
>>>> <td><a
>>>> href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main
>>>> development list</a>
>>>> <td>No
>>>> - <td>Lazy majority
>>>> + <td>Qualified lazy majority
>>>> <td>No
>>>> <td>Committers
>>>> <td>No
>>>>
>>>
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority vote
type for the RFC process (revised)
Posted by Garren Smith <ga...@apache.org>.
I'm -1 on this.
I agree with Bob on this, especially his point on:
The Qualified Lazy Majority explicitly links an individual contributors
actions with their employee (where they have one) and therefore, in my
opinion, presumes bad faith.
On Wed, Mar 6, 2019 at 10:16 AM Joan Touzet <wo...@apache.org> wrote:
> I vote +1 for the following reason:
>
> The decision Robert proposes below (criteria, guidelines) can't be
> made reasonably if the PMC is already heavily slanted in that
> direction. By the time any such action might be taken, the PMC could
> already be corrupted in that way, meaning such a suggested set
> of criteria and a clear reason for calling it out is effectively
> moot.
>
> I feel this proposal strikes the best balance between pragmatism
> and idealism. It is largely a symbolic gesture, one taken to make
> the community feel better more than something that would actually
> prevent the small amount of collusion necessary (a single vote!)
> to step around it.
>
> It shows we care, and it shows we want to take a step towards being
> proactive against any perceived problem.
>
> I will not be crestfallen if this vote fails, but I will continue
> to advocate for its adoption.
>
> PMC members, please make your voices heard, one way or the other.
>
> -Joan
>
> ----- Original Message -----
> > From: "Robert Newson" <rn...@apache.org>
> > To: dev@couchdb.apache.org
> > Sent: Tuesday, 5 March, 2019 3:37:52 PM
> > Subject: Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority
> vote type for the RFC process (revised)
> >
> > -1 for the following reason:
> >
> > "https://apache.org/foundation/how-it-works.html#hats
> >
> > INDIVIDUALS COMPOSE THE ASF
> > All of the ASF including the board, the other officers, the
> > committers, and the members, are participating as individuals. That
> > is one strength of the ASF, affiliations do not cloud the personal
> > contributions."
> >
> > The Qualified Lazy Majority explicitly links an individual
> > contributors actions with their employee (where they have one) and
> > therefore, in my opinion, presumes bad faith.
> >
> > I agree that some ASF projects appear to have been co-opted by a
> > single company, that some people may believe this is true of CouchDB
> > and this deserves a response.
> >
> > I would vote _for_ a bylaw change that addressed this head-on. For
> > example, if we established a remedy for when this occurs (temporary
> > or permanent suspension, for example) or a definition of what we
> > would consider an occurrence. Obviously that is a hard problem and
> > presumably the reason it hasn't yet been proposed.
> >
> > B.
> >
> > --
> > Robert Samuel Newson
> > rnewson@apache.org
> >
> > On Tue, 5 Mar 2019, at 20:29, Joan Touzet wrote:
> > > (Revised: The Reply-To field on the last email was incorrect. I am
> > > also including the diff of the proposed changes to this email per
> > > request.)
> > >
> > > ------------
> > >
> > > PMC Members,
> > >
> > > This is a VOTE to create or amend our official documents.
> > >
> > > It establishes a new Qualified Lazy Majority voting type, and
> > > amends
> > > the bylaws to use this new type for RFC votes only.
> > >
> > > This vote depends on the RFC vote passing.
> > >
> > > The git branch with the proposed further changes to the bylaws,
> > > beyond the RFC process itself, is here:
> > >
> > >
> > >
> https://github.com/apache/couchdb-www/compare/add-rfc...add-qualified-lazy-majority
> > >
> > > Per our process, this vote occurs on the Main development list
> > > (dev@),
> > > and requires a Lazy 2/3 majority, meaning it requires three binding
> > > +1
> > > votes and twice as many binding +1 votes as binding -1 votes. Only
> > > PMC
> > > Members can vote on this issue, and no veto is allowed.
> > >
> > > This vote will run for one week, ending on 12 March 2019 23:59 UTC.
> > >
> > > -Joan
> > >
> > > ---------------------------------------------------
> > >
> > > diff --git a/bylaws.html b/bylaws.html
> > > index 4aea136..7503b88 100644
> > > --- a/bylaws.html
> > > +++ b/bylaws.html
> > > @@ -262,7 +262,7 @@
> > >
> > > <h3 id="approval">3.4. Approval Models</h3>
> > >
> > > -<p><strong>We use three different approval models for formal
> > > voting</strong>:
> > > +<p><strong>We use four different approval models for formal
> > > voting</strong>:
> > >
> > > <ul>
> > > <li>RTC (see section 3.5)
> > > @@ -273,6 +273,11 @@
> > > <ul>
> > > <li>Requires three binding +1 votes and more binding +1
> > > votes
> > > than binding -1 votes
> > > </ul>
> > > + <li>Qualified lazy majority
> > > + <ul>
> > > + <li>Requires three binding +1 votes and more binding +1
> > > votes
> > > than binding -1 votes
> > > + <li>In addition, at least one binding +1 vote must be from
> > > an
> > > individual not directly affiliated with the proposer's employer (if
> > > applicable)
> > > + </ul>
> > > <li>Lazy 2/3 majority
> > > <ul>
> > > <li>Requires three binding +1 votes and twice as many
> > > binding
> > > +1 votes as binding -1 votes
> > > @@ -281,6 +286,8 @@
> > >
> > > <p>RTC is only ever used in the context of a code review or a pull
> > > request, and does not require a separate vote thread. Each of the
> > > other
> > > approval models requires a vote thread.
> > >
> > > +<p>Qualified lazy majority is only used for the <a href="#rfc">RFC
> > > process</a>.</p>
> > > +
> > > <p>A -1 vote is never called a veto except when using the RTC
> > > approval
> > > model. This is because a single -1 vote never has the power to
> > > block a
> > > vote outside of RTC.
> > >
> > > <p>Which approval model to use is dictated by the table in section
> > > 3.6. This is project policy, and can be changed by amending this
> > > document.
> > > @@ -316,7 +323,7 @@ The process is:
> > > <ul>
> > > <li>Start a [DISCUSS] thread on <a
> > > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the
> > > developer mailing list</a>. Discuss your proposal in detail,
> > > including
> > > which modules/applications are affected, any HTTP API additions and
> > > deprecations, and security issues.</li>
> > > <li>When there is consensus on the approach from the
> > > community, <a
> > > href="https://s.apache.org/CouchDB-RFC">complete the RFC
> > > template</a>
> > > and work through any final revisions to the document, with the
> > > support
> > > of the developer mailing list.</li>
> > > - <li>Start the RFC <strong>vote</strong> on the developer
> > > mailing
> > > list. Hold the vote according to the <em>lazy majority
> > > process</em>: at
> > > least 3 +1 votes, and more binding +1 than binding -1 votes.</li>
> > > + <li>Start the RFC <strong>vote</strong> on the developer
> > > mailing
> > > list. Hold the vote according to the <em>qualified lazy majority
> > > process</em>: at least 3 +1 votes, more +1 than -1 votes, and at
> > > least
> > > one +1 vote must be from someone not directly affiliated with the
> > > proposer's employer.</li>
> > > </ul>
> > >
> > > <h3 id="api">3.7 API changes and deprecations</h3>
> > > @@ -355,7 +362,7 @@ The process is:
> > > <td>A decision on a specific proposal to alter CouchDB in a
> > > significant way.
> > > <td><a
> > > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main
> > > development list</a>
> > > <td>No
> > > - <td>Lazy majority
> > > + <td>Qualified lazy majority
> > > <td>No
> > > <td>Committers
> > > <td>No
> > >
> >
>
Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority vote
type for the RFC process (revised)
Posted by Joan Touzet <wo...@apache.org>.
I vote +1 for the following reason:
The decision Robert proposes below (criteria, guidelines) can't be
made reasonably if the PMC is already heavily slanted in that
direction. By the time any such action might be taken, the PMC could
already be corrupted in that way, meaning such a suggested set
of criteria and a clear reason for calling it out is effectively
moot.
I feel this proposal strikes the best balance between pragmatism
and idealism. It is largely a symbolic gesture, one taken to make
the community feel better more than something that would actually
prevent the small amount of collusion necessary (a single vote!)
to step around it.
It shows we care, and it shows we want to take a step towards being
proactive against any perceived problem.
I will not be crestfallen if this vote fails, but I will continue
to advocate for its adoption.
PMC members, please make your voices heard, one way or the other.
-Joan
----- Original Message -----
> From: "Robert Newson" <rn...@apache.org>
> To: dev@couchdb.apache.org
> Sent: Tuesday, 5 March, 2019 3:37:52 PM
> Subject: Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority vote type for the RFC process (revised)
>
> -1 for the following reason:
>
> "https://apache.org/foundation/how-it-works.html#hats
>
> INDIVIDUALS COMPOSE THE ASF
> All of the ASF including the board, the other officers, the
> committers, and the members, are participating as individuals. That
> is one strength of the ASF, affiliations do not cloud the personal
> contributions."
>
> The Qualified Lazy Majority explicitly links an individual
> contributors actions with their employee (where they have one) and
> therefore, in my opinion, presumes bad faith.
>
> I agree that some ASF projects appear to have been co-opted by a
> single company, that some people may believe this is true of CouchDB
> and this deserves a response.
>
> I would vote _for_ a bylaw change that addressed this head-on. For
> example, if we established a remedy for when this occurs (temporary
> or permanent suspension, for example) or a definition of what we
> would consider an occurrence. Obviously that is a hard problem and
> presumably the reason it hasn't yet been proposed.
>
> B.
>
> --
> Robert Samuel Newson
> rnewson@apache.org
>
> On Tue, 5 Mar 2019, at 20:29, Joan Touzet wrote:
> > (Revised: The Reply-To field on the last email was incorrect. I am
> > also including the diff of the proposed changes to this email per
> > request.)
> >
> > ------------
> >
> > PMC Members,
> >
> > This is a VOTE to create or amend our official documents.
> >
> > It establishes a new Qualified Lazy Majority voting type, and
> > amends
> > the bylaws to use this new type for RFC votes only.
> >
> > This vote depends on the RFC vote passing.
> >
> > The git branch with the proposed further changes to the bylaws,
> > beyond the RFC process itself, is here:
> >
> >
> > https://github.com/apache/couchdb-www/compare/add-rfc...add-qualified-lazy-majority
> >
> > Per our process, this vote occurs on the Main development list
> > (dev@),
> > and requires a Lazy 2/3 majority, meaning it requires three binding
> > +1
> > votes and twice as many binding +1 votes as binding -1 votes. Only
> > PMC
> > Members can vote on this issue, and no veto is allowed.
> >
> > This vote will run for one week, ending on 12 March 2019 23:59 UTC.
> >
> > -Joan
> >
> > ---------------------------------------------------
> >
> > diff --git a/bylaws.html b/bylaws.html
> > index 4aea136..7503b88 100644
> > --- a/bylaws.html
> > +++ b/bylaws.html
> > @@ -262,7 +262,7 @@
> >
> > <h3 id="approval">3.4. Approval Models</h3>
> >
> > -<p><strong>We use three different approval models for formal
> > voting</strong>:
> > +<p><strong>We use four different approval models for formal
> > voting</strong>:
> >
> > <ul>
> > <li>RTC (see section 3.5)
> > @@ -273,6 +273,11 @@
> > <ul>
> > <li>Requires three binding +1 votes and more binding +1
> > votes
> > than binding -1 votes
> > </ul>
> > + <li>Qualified lazy majority
> > + <ul>
> > + <li>Requires three binding +1 votes and more binding +1
> > votes
> > than binding -1 votes
> > + <li>In addition, at least one binding +1 vote must be from
> > an
> > individual not directly affiliated with the proposer's employer (if
> > applicable)
> > + </ul>
> > <li>Lazy 2/3 majority
> > <ul>
> > <li>Requires three binding +1 votes and twice as many
> > binding
> > +1 votes as binding -1 votes
> > @@ -281,6 +286,8 @@
> >
> > <p>RTC is only ever used in the context of a code review or a pull
> > request, and does not require a separate vote thread. Each of the
> > other
> > approval models requires a vote thread.
> >
> > +<p>Qualified lazy majority is only used for the <a href="#rfc">RFC
> > process</a>.</p>
> > +
> > <p>A -1 vote is never called a veto except when using the RTC
> > approval
> > model. This is because a single -1 vote never has the power to
> > block a
> > vote outside of RTC.
> >
> > <p>Which approval model to use is dictated by the table in section
> > 3.6. This is project policy, and can be changed by amending this
> > document.
> > @@ -316,7 +323,7 @@ The process is:
> > <ul>
> > <li>Start a [DISCUSS] thread on <a
> > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the
> > developer mailing list</a>. Discuss your proposal in detail,
> > including
> > which modules/applications are affected, any HTTP API additions and
> > deprecations, and security issues.</li>
> > <li>When there is consensus on the approach from the
> > community, <a
> > href="https://s.apache.org/CouchDB-RFC">complete the RFC
> > template</a>
> > and work through any final revisions to the document, with the
> > support
> > of the developer mailing list.</li>
> > - <li>Start the RFC <strong>vote</strong> on the developer
> > mailing
> > list. Hold the vote according to the <em>lazy majority
> > process</em>: at
> > least 3 +1 votes, and more binding +1 than binding -1 votes.</li>
> > + <li>Start the RFC <strong>vote</strong> on the developer
> > mailing
> > list. Hold the vote according to the <em>qualified lazy majority
> > process</em>: at least 3 +1 votes, more +1 than -1 votes, and at
> > least
> > one +1 vote must be from someone not directly affiliated with the
> > proposer's employer.</li>
> > </ul>
> >
> > <h3 id="api">3.7 API changes and deprecations</h3>
> > @@ -355,7 +362,7 @@ The process is:
> > <td>A decision on a specific proposal to alter CouchDB in a
> > significant way.
> > <td><a
> > href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main
> > development list</a>
> > <td>No
> > - <td>Lazy majority
> > + <td>Qualified lazy majority
> > <td>No
> > <td>Committers
> > <td>No
> >
>
Re: [VOTE] Bylaws change: Establish a Qualified Lazy Majority vote type for the RFC process (revised)
Posted by Robert Newson <rn...@apache.org>.
-1 for the following reason:
"https://apache.org/foundation/how-it-works.html#hats
INDIVIDUALS COMPOSE THE ASF
All of the ASF including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the ASF, affiliations do not cloud the personal contributions."
The Qualified Lazy Majority explicitly links an individual contributors actions with their employee (where they have one) and therefore, in my opinion, presumes bad faith.
I agree that some ASF projects appear to have been co-opted by a single company, that some people may believe this is true of CouchDB and this deserves a response.
I would vote _for_ a bylaw change that addressed this head-on. For example, if we established a remedy for when this occurs (temporary or permanent suspension, for example) or a definition of what we would consider an occurrence. Obviously that is a hard problem and presumably the reason it hasn't yet been proposed.
B.
--
Robert Samuel Newson
rnewson@apache.org
On Tue, 5 Mar 2019, at 20:29, Joan Touzet wrote:
> (Revised: The Reply-To field on the last email was incorrect. I am
> also including the diff of the proposed changes to this email per
> request.)
>
> ------------
>
> PMC Members,
>
> This is a VOTE to create or amend our official documents.
>
> It establishes a new Qualified Lazy Majority voting type, and amends
> the bylaws to use this new type for RFC votes only.
>
> This vote depends on the RFC vote passing.
>
> The git branch with the proposed further changes to the bylaws,
> beyond the RFC process itself, is here:
>
>
> https://github.com/apache/couchdb-www/compare/add-rfc...add-qualified-lazy-majority
>
> Per our process, this vote occurs on the Main development list (dev@),
> and requires a Lazy 2/3 majority, meaning it requires three binding +1
> votes and twice as many binding +1 votes as binding -1 votes. Only PMC
> Members can vote on this issue, and no veto is allowed.
>
> This vote will run for one week, ending on 12 March 2019 23:59 UTC.
>
> -Joan
>
> ---------------------------------------------------
>
> diff --git a/bylaws.html b/bylaws.html
> index 4aea136..7503b88 100644
> --- a/bylaws.html
> +++ b/bylaws.html
> @@ -262,7 +262,7 @@
>
> <h3 id="approval">3.4. Approval Models</h3>
>
> -<p><strong>We use three different approval models for formal voting</strong>:
> +<p><strong>We use four different approval models for formal voting</strong>:
>
> <ul>
> <li>RTC (see section 3.5)
> @@ -273,6 +273,11 @@
> <ul>
> <li>Requires three binding +1 votes and more binding +1 votes
> than binding -1 votes
> </ul>
> + <li>Qualified lazy majority
> + <ul>
> + <li>Requires three binding +1 votes and more binding +1 votes
> than binding -1 votes
> + <li>In addition, at least one binding +1 vote must be from an
> individual not directly affiliated with the proposer's employer (if
> applicable)
> + </ul>
> <li>Lazy 2/3 majority
> <ul>
> <li>Requires three binding +1 votes and twice as many binding
> +1 votes as binding -1 votes
> @@ -281,6 +286,8 @@
>
> <p>RTC is only ever used in the context of a code review or a pull
> request, and does not require a separate vote thread. Each of the other
> approval models requires a vote thread.
>
> +<p>Qualified lazy majority is only used for the <a href="#rfc">RFC
> process</a>.</p>
> +
> <p>A -1 vote is never called a veto except when using the RTC approval
> model. This is because a single -1 vote never has the power to block a
> vote outside of RTC.
>
> <p>Which approval model to use is dictated by the table in section
> 3.6. This is project policy, and can be changed by amending this
> document.
> @@ -316,7 +323,7 @@ The process is:
> <ul>
> <li>Start a [DISCUSS] thread on <a
> href="https://lists.apache.org/list.html?dev@couchdb.apache.org">the
> developer mailing list</a>. Discuss your proposal in detail, including
> which modules/applications are affected, any HTTP API additions and
> deprecations, and security issues.</li>
> <li>When there is consensus on the approach from the community, <a
> href="https://s.apache.org/CouchDB-RFC">complete the RFC template</a>
> and work through any final revisions to the document, with the support
> of the developer mailing list.</li>
> - <li>Start the RFC <strong>vote</strong> on the developer mailing
> list. Hold the vote according to the <em>lazy majority process</em>: at
> least 3 +1 votes, and more binding +1 than binding -1 votes.</li>
> + <li>Start the RFC <strong>vote</strong> on the developer mailing
> list. Hold the vote according to the <em>qualified lazy majority
> process</em>: at least 3 +1 votes, more +1 than -1 votes, and at least
> one +1 vote must be from someone not directly affiliated with the
> proposer's employer.</li>
> </ul>
>
> <h3 id="api">3.7 API changes and deprecations</h3>
> @@ -355,7 +362,7 @@ The process is:
> <td>A decision on a specific proposal to alter CouchDB in a
> significant way.
> <td><a
> href="https://lists.apache.org/list.html?dev@couchdb.apache.org">Main
> development list</a>
> <td>No
> - <td>Lazy majority
> + <td>Qualified lazy majority
> <td>No
> <td>Committers
> <td>No
>