Re: How to vote on a patch in JIRA...

[Noah Slater <ns...@apache.org>]

This is very irregular.

I just checked the bylaws, and we have the following verbiage:

"one +1 from a committer who has not authored the patch followed by a
Lazy approval (not counting the vote of the contributor), moving to
lazy majority if a -1 is received"

There are four red flags here:

 - A single +1 vote for a proposal to pass seems irregular. (Though I
note that Hadoop uses it. Though, remember that Hadoop is a very big
project and may have problems that we do not.)
 - Whereas every other type of decision uses a defined voting model,
code modification does not, and invents one for itself inside the
little "Approval" box
 - The ad-hoc voting model in the "Approval" box is actually two
voting models. If one fails, a new one is used.
 - The model you switch to if a -1 is received effectively does way
with the idea of code vetos. This seems unusual, and dangerous.

I think this needs to be fixed.

I do not like RTC, as I think it adds unnecessary friction to the
contribution process. I think a true lazy consensus approach is much
better. Lazy consensus says that if you think this commit is good for
the project, you may perform it. And we will review it and tell you if
we think it needs changing. (Remember: our VCS is a time-machine!)

This is a very good page on lazy consensus:

http://rave.apache.org/docs/governance/lazyConsensus.html

Note that the "lazy consensus" mentioned in the bylaws is not actually
lazy consensus. This is an error that was carried over from the Kafka
bylaws. (I have emailed them separately to correct it.)

However, if this community still prefers CTR (despite my
protestations) I suggest you define the voting model "Approvals"
section. And I would recommend that it be defined as:

"Consensus check requires 3 binding +1 votes and no binding vetoes."

(Yes, I just invented a term, consensus check, to be like a
lightweight version of a consensus approval vote.)

On 6 September 2013 12:49, Kasper Sørensen
<i....@gmail.com> wrote:
> +1 :-)
>
> I agree to those rules that you just sketched there (RTC / min 1 vote / 48
> hours lazy commit).
>
>
> 2013/9/5 Henry Saputra <he...@gmail.com>
>
>> I guess it is the good time to discuss about the MetaModel bylaws =)
>>
>> Here is the link to how ASF Voting process:
>> http://www.apache.org/foundation/voting.html
>>
>> As indicated by the link [1], unless a vote is declared as lazy
>> consensus dictate three +1 votes are required for a code-modification
>> proposal to pass.
>>
>> And it is usually added to the JIRA to track down the vote process.
>>
>> We will need to create bylaws page in wiki or website to help new
>> developers understand how we operate.
>>
>> If it is agreed upon, we could use review-then-commits with at least 1
>> vote to commit and if no response in 48 hours we could invoke lazy
>> consensus to get the patch going
>>
>> - Henry
>>
>> [1] http://www.apache.org/foundation/voting.html
>>
>> On Thu, Sep 5, 2013 at 12:29 AM, Kasper Sørensen
>> <i....@gmail.com> wrote:
>> > Hi all,
>> >
>> > I wanted to clarify something now since we have seen a few times that
>> > people submit patches directly to JIRA. Which is fine :-)
>> >
>> > But how should we do voting on the patches then? Will we treat JIRA
>> > comments just like any other mail reply, and simply post our "+1"s on the
>> > JIRA issue itself? I also see JIRA has a voting mechanism although I
>> > haven't tried it. Finally we could also opt for re-raising the patch in
>> the
>> > mailing list and only do the votes by mail.
>> >
>> > What do you think is best, and what's common practice for Apache
>> projects?
>> >
>> > Kasper
>> >
>> > PS: Either way is fine by me :-)
>>



-- 
Noah Slater
https://twitter.com/nslater

Re: How to vote on a patch in JIRA...

[Noah Slater <ns...@apache.org>]

I'd suggest you start a [DISCUSS] thread on dev with a clear subject
line and try to get consensus through discussion first. Once you think
you have consensus, tie it up with a vote. In general, voting should
be rare, and only used to "officiate" a consensus that was reached
through discussion.

On 19 November 2013 15:14, Kasper Sørensen
<i....@gmail.com> wrote:
> Sorry for chiming in so late ...
>
> Noah, I think I agree to what you're saying. And this was only a draft and
> as you see it was mostly a edited copy/paste of Kafka's by laws.
>
> Wrt. lazy concensus or not - I would go for the thing that we believe
> maximizes the involvement of the community. Obviously for a committer like
> myself it's much more practical with CTR... But might not be the opinion of
> outside people. On the other hand they could simply "commit" by making a
> pull request, patch or something like that and I think that is fine.
>
> Shall we do a vote on the CTR vs RTC approach?
>
>
> 2013/11/14 Noah Slater <ns...@apache.org>
>>
>> Sorry, I meant:
>>
>> "Consensus check requires 1 binding +1 vote and no binding vetoes."
>>
>> On 14 November 2013 15:31, Noah Slater <ns...@apache.org> wrote:
>> > This is very irregular.
>> >
>> > I just checked the bylaws, and we have the following verbiage:
>> >
>> > "one +1 from a committer who has not authored the patch followed by a
>> > Lazy approval (not counting the vote of the contributor), moving to
>> > lazy majority if a -1 is received"
>> >
>> > There are four red flags here:
>> >
>> >  - A single +1 vote for a proposal to pass seems irregular. (Though I
>> > note that Hadoop uses it. Though, remember that Hadoop is a very big
>> > project and may have problems that we do not.)
>> >  - Whereas every other type of decision uses a defined voting model,
>> > code modification does not, and invents one for itself inside the
>> > little "Approval" box
>> >  - The ad-hoc voting model in the "Approval" box is actually two
>> > voting models. If one fails, a new one is used.
>> >  - The model you switch to if a -1 is received effectively does way
>> > with the idea of code vetos. This seems unusual, and dangerous.
>> >
>> > I think this needs to be fixed.
>> >
>> > I do not like RTC, as I think it adds unnecessary friction to the
>> > contribution process. I think a true lazy consensus approach is much
>> > better. Lazy consensus says that if you think this commit is good for
>> > the project, you may perform it. And we will review it and tell you if
>> > we think it needs changing. (Remember: our VCS is a time-machine!)
>> >
>> > This is a very good page on lazy consensus:
>> >
>> > http://rave.apache.org/docs/governance/lazyConsensus.html
>> >
>> > Note that the "lazy consensus" mentioned in the bylaws is not actually
>> > lazy consensus. This is an error that was carried over from the Kafka
>> > bylaws. (I have emailed them separately to correct it.)
>> >
>> > However, if this community still prefers CTR (despite my
>> > protestations) I suggest you define the voting model "Approvals"
>> > section. And I would recommend that it be defined as:
>> >
>> > "Consensus check requires 3 binding +1 votes and no binding vetoes."
>> >
>> > (Yes, I just invented a term, consensus check, to be like a
>> > lightweight version of a consensus approval vote.)
>> >
>> > On 6 September 2013 12:49, Kasper Sørensen
>> > <i....@gmail.com> wrote:
>> >> +1 :-)
>> >>
>> >> I agree to those rules that you just sketched there (RTC / min 1 vote /
>> >> 48
>> >> hours lazy commit).
>> >>
>> >>
>> >> 2013/9/5 Henry Saputra <he...@gmail.com>
>> >>
>> >>> I guess it is the good time to discuss about the MetaModel bylaws =)
>> >>>
>> >>> Here is the link to how ASF Voting process:
>> >>> http://www.apache.org/foundation/voting.html
>> >>>
>> >>> As indicated by the link [1], unless a vote is declared as lazy
>> >>> consensus dictate three +1 votes are required for a code-modification
>> >>> proposal to pass.
>> >>>
>> >>> And it is usually added to the JIRA to track down the vote process.
>> >>>
>> >>> We will need to create bylaws page in wiki or website to help new
>> >>> developers understand how we operate.
>> >>>
>> >>> If it is agreed upon, we could use review-then-commits with at least 1
>> >>> vote to commit and if no response in 48 hours we could invoke lazy
>> >>> consensus to get the patch going
>> >>>
>> >>> - Henry
>> >>>
>> >>> [1] http://www.apache.org/foundation/voting.html
>> >>>
>> >>> On Thu, Sep 5, 2013 at 12:29 AM, Kasper Sørensen
>> >>> <i....@gmail.com> wrote:
>> >>> > Hi all,
>> >>> >
>> >>> > I wanted to clarify something now since we have seen a few times
>> >>> > that
>> >>> > people submit patches directly to JIRA. Which is fine :-)
>> >>> >
>> >>> > But how should we do voting on the patches then? Will we treat JIRA
>> >>> > comments just like any other mail reply, and simply post our "+1"s
>> >>> > on the
>> >>> > JIRA issue itself? I also see JIRA has a voting mechanism although I
>> >>> > haven't tried it. Finally we could also opt for re-raising the patch
>> >>> > in
>> >>> the
>> >>> > mailing list and only do the votes by mail.
>> >>> >
>> >>> > What do you think is best, and what's common practice for Apache
>> >>> projects?
>> >>> >
>> >>> > Kasper
>> >>> >
>> >>> > PS: Either way is fine by me :-)
>> >>>
>> >
>> >
>> >
>> > --
>> > Noah Slater
>> > https://twitter.com/nslater
>>
>>
>>
>> --
>> Noah Slater
>> https://twitter.com/nslater
>
>



-- 
Noah Slater
https://twitter.com/nslater

Re: How to vote on a patch in JIRA...

[Kasper Sørensen <i....@gmail.com>]

Sorry for chiming in so late ...

Noah, I think I agree to what you're saying. And this was only a draft and
as you see it was mostly a edited copy/paste of Kafka's by laws.

Wrt. lazy concensus or not - I would go for the thing that we believe
maximizes the involvement of the community. Obviously for a committer like
myself it's much more practical with CTR... But might not be the opinion of
outside people. On the other hand they could simply "commit" by making a
pull request, patch or something like that and I think that is fine.

Shall we do a vote on the CTR vs RTC approach?


2013/11/14 Noah Slater <ns...@apache.org>

> Sorry, I meant:
>
> "Consensus check requires 1 binding +1 vote and no binding vetoes."
>
> On 14 November 2013 15:31, Noah Slater <ns...@apache.org> wrote:
> > This is very irregular.
> >
> > I just checked the bylaws, and we have the following verbiage:
> >
> > "one +1 from a committer who has not authored the patch followed by a
> > Lazy approval (not counting the vote of the contributor), moving to
> > lazy majority if a -1 is received"
> >
> > There are four red flags here:
> >
> >  - A single +1 vote for a proposal to pass seems irregular. (Though I
> > note that Hadoop uses it. Though, remember that Hadoop is a very big
> > project and may have problems that we do not.)
> >  - Whereas every other type of decision uses a defined voting model,
> > code modification does not, and invents one for itself inside the
> > little "Approval" box
> >  - The ad-hoc voting model in the "Approval" box is actually two
> > voting models. If one fails, a new one is used.
> >  - The model you switch to if a -1 is received effectively does way
> > with the idea of code vetos. This seems unusual, and dangerous.
> >
> > I think this needs to be fixed.
> >
> > I do not like RTC, as I think it adds unnecessary friction to the
> > contribution process. I think a true lazy consensus approach is much
> > better. Lazy consensus says that if you think this commit is good for
> > the project, you may perform it. And we will review it and tell you if
> > we think it needs changing. (Remember: our VCS is a time-machine!)
> >
> > This is a very good page on lazy consensus:
> >
> > http://rave.apache.org/docs/governance/lazyConsensus.html
> >
> > Note that the "lazy consensus" mentioned in the bylaws is not actually
> > lazy consensus. This is an error that was carried over from the Kafka
> > bylaws. (I have emailed them separately to correct it.)
> >
> > However, if this community still prefers CTR (despite my
> > protestations) I suggest you define the voting model "Approvals"
> > section. And I would recommend that it be defined as:
> >
> > "Consensus check requires 3 binding +1 votes and no binding vetoes."
> >
> > (Yes, I just invented a term, consensus check, to be like a
> > lightweight version of a consensus approval vote.)
> >
> > On 6 September 2013 12:49, Kasper Sørensen
> > <i....@gmail.com> wrote:
> >> +1 :-)
> >>
> >> I agree to those rules that you just sketched there (RTC / min 1 vote /
> 48
> >> hours lazy commit).
> >>
> >>
> >> 2013/9/5 Henry Saputra <he...@gmail.com>
> >>
> >>> I guess it is the good time to discuss about the MetaModel bylaws =)
> >>>
> >>> Here is the link to how ASF Voting process:
> >>> http://www.apache.org/foundation/voting.html
> >>>
> >>> As indicated by the link [1], unless a vote is declared as lazy
> >>> consensus dictate three +1 votes are required for a code-modification
> >>> proposal to pass.
> >>>
> >>> And it is usually added to the JIRA to track down the vote process.
> >>>
> >>> We will need to create bylaws page in wiki or website to help new
> >>> developers understand how we operate.
> >>>
> >>> If it is agreed upon, we could use review-then-commits with at least 1
> >>> vote to commit and if no response in 48 hours we could invoke lazy
> >>> consensus to get the patch going
> >>>
> >>> - Henry
> >>>
> >>> [1] http://www.apache.org/foundation/voting.html
> >>>
> >>> On Thu, Sep 5, 2013 at 12:29 AM, Kasper Sørensen
> >>> <i....@gmail.com> wrote:
> >>> > Hi all,
> >>> >
> >>> > I wanted to clarify something now since we have seen a few times that
> >>> > people submit patches directly to JIRA. Which is fine :-)
> >>> >
> >>> > But how should we do voting on the patches then? Will we treat JIRA
> >>> > comments just like any other mail reply, and simply post our "+1"s
> on the
> >>> > JIRA issue itself? I also see JIRA has a voting mechanism although I
> >>> > haven't tried it. Finally we could also opt for re-raising the patch
> in
> >>> the
> >>> > mailing list and only do the votes by mail.
> >>> >
> >>> > What do you think is best, and what's common practice for Apache
> >>> projects?
> >>> >
> >>> > Kasper
> >>> >
> >>> > PS: Either way is fine by me :-)
> >>>
> >
> >
> >
> > --
> > Noah Slater
> > https://twitter.com/nslater
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater
>

Re: How to vote on a patch in JIRA...

[Noah Slater <ns...@apache.org>]

Sorry, I meant:

"Consensus check requires 1 binding +1 vote and no binding vetoes."

On 14 November 2013 15:31, Noah Slater <ns...@apache.org> wrote:
> This is very irregular.
>
> I just checked the bylaws, and we have the following verbiage:
>
> "one +1 from a committer who has not authored the patch followed by a
> Lazy approval (not counting the vote of the contributor), moving to
> lazy majority if a -1 is received"
>
> There are four red flags here:
>
>  - A single +1 vote for a proposal to pass seems irregular. (Though I
> note that Hadoop uses it. Though, remember that Hadoop is a very big
> project and may have problems that we do not.)
>  - Whereas every other type of decision uses a defined voting model,
> code modification does not, and invents one for itself inside the
> little "Approval" box
>  - The ad-hoc voting model in the "Approval" box is actually two
> voting models. If one fails, a new one is used.
>  - The model you switch to if a -1 is received effectively does way
> with the idea of code vetos. This seems unusual, and dangerous.
>
> I think this needs to be fixed.
>
> I do not like RTC, as I think it adds unnecessary friction to the
> contribution process. I think a true lazy consensus approach is much
> better. Lazy consensus says that if you think this commit is good for
> the project, you may perform it. And we will review it and tell you if
> we think it needs changing. (Remember: our VCS is a time-machine!)
>
> This is a very good page on lazy consensus:
>
> http://rave.apache.org/docs/governance/lazyConsensus.html
>
> Note that the "lazy consensus" mentioned in the bylaws is not actually
> lazy consensus. This is an error that was carried over from the Kafka
> bylaws. (I have emailed them separately to correct it.)
>
> However, if this community still prefers CTR (despite my
> protestations) I suggest you define the voting model "Approvals"
> section. And I would recommend that it be defined as:
>
> "Consensus check requires 3 binding +1 votes and no binding vetoes."
>
> (Yes, I just invented a term, consensus check, to be like a
> lightweight version of a consensus approval vote.)
>
> On 6 September 2013 12:49, Kasper Sørensen
> <i....@gmail.com> wrote:
>> +1 :-)
>>
>> I agree to those rules that you just sketched there (RTC / min 1 vote / 48
>> hours lazy commit).
>>
>>
>> 2013/9/5 Henry Saputra <he...@gmail.com>
>>
>>> I guess it is the good time to discuss about the MetaModel bylaws =)
>>>
>>> Here is the link to how ASF Voting process:
>>> http://www.apache.org/foundation/voting.html
>>>
>>> As indicated by the link [1], unless a vote is declared as lazy
>>> consensus dictate three +1 votes are required for a code-modification
>>> proposal to pass.
>>>
>>> And it is usually added to the JIRA to track down the vote process.
>>>
>>> We will need to create bylaws page in wiki or website to help new
>>> developers understand how we operate.
>>>
>>> If it is agreed upon, we could use review-then-commits with at least 1
>>> vote to commit and if no response in 48 hours we could invoke lazy
>>> consensus to get the patch going
>>>
>>> - Henry
>>>
>>> [1] http://www.apache.org/foundation/voting.html
>>>
>>> On Thu, Sep 5, 2013 at 12:29 AM, Kasper Sørensen
>>> <i....@gmail.com> wrote:
>>> > Hi all,
>>> >
>>> > I wanted to clarify something now since we have seen a few times that
>>> > people submit patches directly to JIRA. Which is fine :-)
>>> >
>>> > But how should we do voting on the patches then? Will we treat JIRA
>>> > comments just like any other mail reply, and simply post our "+1"s on the
>>> > JIRA issue itself? I also see JIRA has a voting mechanism although I
>>> > haven't tried it. Finally we could also opt for re-raising the patch in
>>> the
>>> > mailing list and only do the votes by mail.
>>> >
>>> > What do you think is best, and what's common practice for Apache
>>> projects?
>>> >
>>> > Kasper
>>> >
>>> > PS: Either way is fine by me :-)
>>>
>
>
>
> --
> Noah Slater
> https://twitter.com/nslater



-- 
Noah Slater
https://twitter.com/nslater