You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Konstantin Boudnik <co...@apache.org> on 2015/11/21 20:34:59 UTC
[VOTE] Accepting CTR policy for the project
Using CTR for the Bigtop project has been discussed, experimented for a few
months, and discussed again on this long thread [1] for alomost a year now. The
consensus seems to be reached, but because this is a policy change I'd like to
bring it up for the vote.
So, please cast your for per the following ledger
[ ] +1, make the CTR policy permanent for the Bigtop project
[ ] +0, I don't care either way,
[ ] -1, do not make the CTR policy permanent for the Bigtop project because...
The vote will be open for at least 72 hours and will be closed on Tuesday, Nov
24 at noon PST.
[1] http://is.gd/TgBovX
Thanks,
Cos
Re: [VOTE] Accepting CTR policy for the project
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Nov 21, 2015 at 11:34 AM, Konstantin Boudnik <co...@apache.org> wrote:
> Using CTR for the Bigtop project has been discussed, experimented for a few
> months, and discussed again on this long thread [1] for alomost a year now. The
> consensus seems to be reached, but because this is a policy change I'd like to
> bring it up for the vote.
>
> So, please cast your for per the following ledger
>
> [ ] +1, make the CTR policy permanent for the Bigtop project
> [ ] +0, I don't care either way,
> [ ] -1, do not make the CTR policy permanent for the Bigtop project because...
+1
Thanks,
Roman.
Re: [VOTE] Accepting CTR policy for the project
Posted by Olaf Flebbe <of...@oflebbe.de>.
+1, thanks!
> Am 21.11.2015 um 20:34 schrieb Konstantin Boudnik <co...@apache.org>:
>
> Using CTR for the Bigtop project has been discussed, experimented for a few
> months, and discussed again on this long thread [1] for alomost a year now. The
> consensus seems to be reached, but because this is a policy change I'd like to
> bring it up for the vote.
>
> So, please cast your for per the following ledger
>
> [ ] +1, make the CTR policy permanent for the Bigtop project
> [ ] +0, I don't care either way,
> [ ] -1, do not make the CTR policy permanent for the Bigtop project because...
>
> The vote will be open for at least 72 hours and will be closed on Tuesday, Nov
> 24 at noon PST.
>
> [1] http://is.gd/TgBovX
>
> Thanks,
> Cos
>
>
>
>
Re: [VOTE] Accepting CTR policy for the project
Posted by Andre Arcilla <ar...@apache.org>.
+1.
Thanks
On Sun, Nov 22, 2015 at 5:50 PM, RJ Nowling <rn...@gmail.com> wrote:
> +1
>
> On Sun, Nov 22, 2015 at 11:58 AM, Konstantin Boudnik <co...@apache.org>
> wrote:
>
> > +1
> >
> > On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
> > > Using CTR for the Bigtop project has been discussed, experimented for a
> > few
> > > months, and discussed again on this long thread [1] for alomost a year
> > now. The
> > > consensus seems to be reached, but because this is a policy change I'd
> > like to
> > > bring it up for the vote.
> > >
> > > So, please cast your for per the following ledger
> > >
> > > [ ] +1, make the CTR policy permanent for the Bigtop project
> > > [ ] +0, I don't care either way,
> > > [ ] -1, do not make the CTR policy permanent for the Bigtop project
> > because...
> > >
> > > The vote will be open for at least 72 hours and will be closed on
> > Tuesday, Nov
> > > 24 at noon PST.
> > >
> > > [1] http://is.gd/TgBovX
> > >
> > > Thanks,
> > > Cos
> > >
> > >
> > >
> > >
> >
> >
> >
>
Re: [VOTE] Accepting CTR policy for the project
Posted by RJ Nowling <rn...@gmail.com>.
+1
On Sun, Nov 22, 2015 at 11:58 AM, Konstantin Boudnik <co...@apache.org> wrote:
> +1
>
> On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
> > Using CTR for the Bigtop project has been discussed, experimented for a
> few
> > months, and discussed again on this long thread [1] for alomost a year
> now. The
> > consensus seems to be reached, but because this is a policy change I'd
> like to
> > bring it up for the vote.
> >
> > So, please cast your for per the following ledger
> >
> > [ ] +1, make the CTR policy permanent for the Bigtop project
> > [ ] +0, I don't care either way,
> > [ ] -1, do not make the CTR policy permanent for the Bigtop project
> because...
> >
> > The vote will be open for at least 72 hours and will be closed on
> Tuesday, Nov
> > 24 at noon PST.
> >
> > [1] http://is.gd/TgBovX
> >
> > Thanks,
> > Cos
> >
> >
> >
> >
>
>
>
Re: [VOTE] Accepting CTR policy for the project
Posted by Konstantin Boudnik <co...@apache.org>.
+1
On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
> Using CTR for the Bigtop project has been discussed, experimented for a few
> months, and discussed again on this long thread [1] for alomost a year now. The
> consensus seems to be reached, but because this is a policy change I'd like to
> bring it up for the vote.
>
> So, please cast your for per the following ledger
>
> [ ] +1, make the CTR policy permanent for the Bigtop project
> [ ] +0, I don't care either way,
> [ ] -1, do not make the CTR policy permanent for the Bigtop project because...
>
> The vote will be open for at least 72 hours and will be closed on Tuesday, Nov
> 24 at noon PST.
>
> [1] http://is.gd/TgBovX
>
> Thanks,
> Cos
>
>
>
>
Re: [VOTE] Accepting CTR policy for the project
Posted by Jay Vyas <ja...@gmail.com>.
+1
> On Nov 21, 2015, at 2:34 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> Using CTR for the Bigtop project has been discussed, experimented for a few
> months, and discussed again on this long thread [1] for alomost a year now. The
> consensus seems to be reached, but because this is a policy change I'd like to
> bring it up for the vote.
>
> So, please cast your for per the following ledger
>
> [ ] +1, make the CTR policy permanent for the Bigtop project
> [ ] +0, I don't care either way,
> [ ] -1, do not make the CTR policy permanent for the Bigtop project because...
>
> The vote will be open for at least 72 hours and will be closed on Tuesday, Nov
> 24 at noon PST.
>
> [1] http://is.gd/TgBovX
>
> Thanks,
> Cos
>
>
>
>
Re: [VOTE] Accepting CTR policy for the project
Posted by Andrew Purtell <an...@gmail.com>.
+1
> On Nov 21, 2015, at 11:34 AM, Konstantin Boudnik <co...@apache.org> wrote:
>
> Using CTR for the Bigtop project has been discussed, experimented for a few
> months, and discussed again on this long thread [1] for alomost a year now. The
> consensus seems to be reached, but because this is a policy change I'd like to
> bring it up for the vote.
>
> So, please cast your for per the following ledger
>
> [ ] +1, make the CTR policy permanent for the Bigtop project
> [ ] +0, I don't care either way,
> [ ] -1, do not make the CTR policy permanent for the Bigtop project because...
>
> The vote will be open for at least 72 hours and will be closed on Tuesday, Nov
> 24 at noon PST.
>
> [1] http://is.gd/TgBovX
>
> Thanks,
> Cos
>
>
>
>
Re: [VOTE] Accepting CTR policy for the project
Posted by "김영우 (YoungWoo Kim)" <yw...@apache.org>.
+1
On Sun, Nov 22, 2015 at 4:34 AM, Konstantin Boudnik <co...@apache.org> wrote:
> Using CTR for the Bigtop project has been discussed, experimented for a few
> months, and discussed again on this long thread [1] for alomost a year
> now. The
> consensus seems to be reached, but because this is a policy change I'd
> like to
> bring it up for the vote.
>
> So, please cast your for per the following ledger
>
> [ ] +1, make the CTR policy permanent for the Bigtop project
> [ ] +0, I don't care either way,
> [ ] -1, do not make the CTR policy permanent for the Bigtop project
> because...
>
> The vote will be open for at least 72 hours and will be closed on Tuesday,
> Nov
> 24 at noon PST.
>
> [1] http://is.gd/TgBovX
>
> Thanks,
> Cos
>
>
>
>
>
Re: CTR vs RTC again [Was: RESULT: [VOTE] Accepting CTR policy for
the project]
Posted by RJ Nowling <rn...@gmail.com>.
+1
I'd in favor of a "soft rule" over a "hard rule". This allows for
flexibility while encouraging folks to try to engage others in the
community more.
On Sun, Jan 22, 2017 at 9:44 PM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Sat, Jan 21, 2017 at 10:22 PM, RJ Nowling <rn...@gmail.com> wrote:
> > I agree with a lot that has been said here. Primarily, that I see RTC
> as a
> > way to increase committer involvement. If we know we need to be actually
> > watching for commits to review, we are more likely to pay attention to
> the
> > project and engage in discussion. I think that more involvement means a
> > more cohesive community.
> >
> > The biggest problem with RTC is that it holds up work by the most active
> > committers, who are the life blood of the project. CTR makes it easier
> for
> > the most active committers to focus on their work of moving the project
> > forward. That part can't be overlooked.
> >
> > However, if there are other ways to encourage community participation,
> then
> > I would propose trying those before trying to revert to RTC.
>
> So far the biggest rationale I can relate to is the one articulated by
> Olaf -- if the project
> doesn't have RTC than important stuff can flow by that not a lot of
> folks realize how to
> use/support (lets assume that the implementation is correct and bug
> free so that the only
> purpose of a peer review would be for others to actually know what's
> getting where).
>
> So what do you folks think about flipping a problem on its head and asking
> the committers still working under the CTR model to always announce any
> kind of major (or even mid-size things on dev@ ?
>
> Would this be too weak of a guarantee?
>
> Thanks,
> Roman.
>
Re: CTR vs RTC again [Was: RESULT: [VOTE] Accepting CTR policy for
the project]
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Jan 21, 2017 at 10:22 PM, RJ Nowling <rn...@gmail.com> wrote:
> I agree with a lot that has been said here. Primarily, that I see RTC as a
> way to increase committer involvement. If we know we need to be actually
> watching for commits to review, we are more likely to pay attention to the
> project and engage in discussion. I think that more involvement means a
> more cohesive community.
>
> The biggest problem with RTC is that it holds up work by the most active
> committers, who are the life blood of the project. CTR makes it easier for
> the most active committers to focus on their work of moving the project
> forward. That part can't be overlooked.
>
> However, if there are other ways to encourage community participation, then
> I would propose trying those before trying to revert to RTC.
So far the biggest rationale I can relate to is the one articulated by
Olaf -- if the project
doesn't have RTC than important stuff can flow by that not a lot of
folks realize how to
use/support (lets assume that the implementation is correct and bug
free so that the only
purpose of a peer review would be for others to actually know what's
getting where).
So what do you folks think about flipping a problem on its head and asking
the committers still working under the CTR model to always announce any
kind of major (or even mid-size things on dev@ ?
Would this be too weak of a guarantee?
Thanks,
Roman.
Re: CTR vs RTC again [Was: RESULT: [VOTE] Accepting CTR policy for
the project]
Posted by RJ Nowling <rn...@gmail.com>.
I agree with a lot that has been said here. Primarily, that I see RTC as a
way to increase committer involvement. If we know we need to be actually
watching for commits to review, we are more likely to pay attention to the
project and engage in discussion. I think that more involvement means a
more cohesive community.
The biggest problem with RTC is that it holds up work by the most active
committers, who are the life blood of the project. CTR makes it easier for
the most active committers to focus on their work of moving the project
forward. That part can't be overlooked.
However, if there are other ways to encourage community participation, then
I would propose trying those before trying to revert to RTC.
On Fri, Jan 20, 2017 at 9:42 PM, Evans Ye <ev...@apache.org> wrote:
> All the other feedback seems reasonable to me. Plus I actually don't know
> whether RTC can solve the problem or not. It's just a try. But I'd like to
> reply in below statements specifically.
>
> > Cos: a mechanical +1 != positive feedback. It is as good a no feedback at
> all.
>
> I actually don't agree with this point.
> There's no mechanical +1 in our community regardless of RTC or CTR.
> I think any committer in our community will at least viewed the patch and
> provide a responsible +1. The only thing makes the +1 to a buggy patch is
> just because of knowledge gap or human errors, which I in my opinion are
> completely acceptable.
> Speaking of knowledge gap, this sort of linked the story with my next
> reply...
>
> > Roman: With all of the above -- what problem is left for us to solve with
> RTC?
>
> One strong reason here posted by Olaf:
>
> > Olaf: I am miss the discussion a lot.
>
> With RTC all the committed stuffs have at least two person knowing that,
> although there's a nondeterministic proportion of "knowing". This serves
> exactly a way to sync up our knowledge. Isn't it?
>
> To sum up, reverting back to RTC is a proposal trying to increase
> discussions in the community.
> If there's a better way to do it. I'm not sticking to RTC at all.
>
>
> 2017-01-20 7:01 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
>
> > On Thu, Jan 19, 2017 at 2:22 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > On Wed, Jan 18, 2017 at 01:43PM, Evans Ye wrote:
> > >> > How many of us have asked for the review/feedback and when they did,
> > the
> > >> > feedback wasn't provided?
> > >>
> > >> This is more about psychology I think.
> > >> For example, if a committer provided a patch and seeking for review.
> > Since
> > >> the committer do not highlighting anyone specifically, no one is
> > >> responsible to review it. And anyhow the patch provider(committer) can
> > just
> > >> go ahead and commit it anyway according to CTR. So, no one feels
> guilty
> > >> about blocking the progress. Therefore no one will review it.
> > >
> > > Let me turn this around: under CTR if one is pro-actively seeking for
> > feedback
> > > but no one replies, the code could still be committed. Under RTC no one
> > is
> > > obliged to provide a feedback to a committer; but in this case the
> patch
> > is
> > > stuck and can not be committed. And still no one fills guilty anyone,
> > because
> > > it is no one fault (aka tragedy of the commons).
> >
> > I don't really have a pony in this race, but I tend to agree with Cos
> > on this one.
> >
> > Evans -- as you said -- it is about human psychology, but that's exactly
> > why
> > I don't think I have a clear understanding of why RTC provides a better
> > setup.
> >
> > After all -- we're all committers, so there's no policy that would
> prevent
> > us
> > from a physical act of git push'ing. Its all about self control.
> >
> > And from that standpoint we can have self-imposed RTC today. Suppose
> > you decide that RTC is better for you -- well then just make it a habit
> to
> > ask for review on this list before every single commit you do. See how it
> > works out for you and either keep doing it or, perhaps, start using your
> > discretion of not asking when you feel really confident.
> >
> > This leaves disruptive pushers. Honestly, I haven't seen too much of that
> > going in so perhaps I don't appreciate the full scope of the problem --
> but
> > it seems to me that RTC won't solve it either.
> >
> > With all of the above -- what problem is left for us to solve with RTC?
> >
> > Thanks,
> > Roman.
> >
>
Re: CTR vs RTC again [Was: RESULT: [VOTE] Accepting CTR policy for
the project]
Posted by Evans Ye <ev...@apache.org>.
All the other feedback seems reasonable to me. Plus I actually don't know
whether RTC can solve the problem or not. It's just a try. But I'd like to
reply in below statements specifically.
> Cos: a mechanical +1 != positive feedback. It is as good a no feedback at
all.
I actually don't agree with this point.
There's no mechanical +1 in our community regardless of RTC or CTR.
I think any committer in our community will at least viewed the patch and
provide a responsible +1. The only thing makes the +1 to a buggy patch is
just because of knowledge gap or human errors, which I in my opinion are
completely acceptable.
Speaking of knowledge gap, this sort of linked the story with my next
reply...
> Roman: With all of the above -- what problem is left for us to solve with
RTC?
One strong reason here posted by Olaf:
> Olaf: I am miss the discussion a lot.
With RTC all the committed stuffs have at least two person knowing that,
although there's a nondeterministic proportion of "knowing". This serves
exactly a way to sync up our knowledge. Isn't it?
To sum up, reverting back to RTC is a proposal trying to increase
discussions in the community.
If there's a better way to do it. I'm not sticking to RTC at all.
2017-01-20 7:01 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
> On Thu, Jan 19, 2017 at 2:22 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > On Wed, Jan 18, 2017 at 01:43PM, Evans Ye wrote:
> >> > How many of us have asked for the review/feedback and when they did,
> the
> >> > feedback wasn't provided?
> >>
> >> This is more about psychology I think.
> >> For example, if a committer provided a patch and seeking for review.
> Since
> >> the committer do not highlighting anyone specifically, no one is
> >> responsible to review it. And anyhow the patch provider(committer) can
> just
> >> go ahead and commit it anyway according to CTR. So, no one feels guilty
> >> about blocking the progress. Therefore no one will review it.
> >
> > Let me turn this around: under CTR if one is pro-actively seeking for
> feedback
> > but no one replies, the code could still be committed. Under RTC no one
> is
> > obliged to provide a feedback to a committer; but in this case the patch
> is
> > stuck and can not be committed. And still no one fills guilty anyone,
> because
> > it is no one fault (aka tragedy of the commons).
>
> I don't really have a pony in this race, but I tend to agree with Cos
> on this one.
>
> Evans -- as you said -- it is about human psychology, but that's exactly
> why
> I don't think I have a clear understanding of why RTC provides a better
> setup.
>
> After all -- we're all committers, so there's no policy that would prevent
> us
> from a physical act of git push'ing. Its all about self control.
>
> And from that standpoint we can have self-imposed RTC today. Suppose
> you decide that RTC is better for you -- well then just make it a habit to
> ask for review on this list before every single commit you do. See how it
> works out for you and either keep doing it or, perhaps, start using your
> discretion of not asking when you feel really confident.
>
> This leaves disruptive pushers. Honestly, I haven't seen too much of that
> going in so perhaps I don't appreciate the full scope of the problem -- but
> it seems to me that RTC won't solve it either.
>
> With all of the above -- what problem is left for us to solve with RTC?
>
> Thanks,
> Roman.
>
Re: CTR vs RTC again [Was: RESULT: [VOTE] Accepting CTR policy for
the project]
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Jan 19, 2017 at 2:22 PM, Konstantin Boudnik <co...@apache.org> wrote:
> On Wed, Jan 18, 2017 at 01:43PM, Evans Ye wrote:
>> > How many of us have asked for the review/feedback and when they did, the
>> > feedback wasn't provided?
>>
>> This is more about psychology I think.
>> For example, if a committer provided a patch and seeking for review. Since
>> the committer do not highlighting anyone specifically, no one is
>> responsible to review it. And anyhow the patch provider(committer) can just
>> go ahead and commit it anyway according to CTR. So, no one feels guilty
>> about blocking the progress. Therefore no one will review it.
>
> Let me turn this around: under CTR if one is pro-actively seeking for feedback
> but no one replies, the code could still be committed. Under RTC no one is
> obliged to provide a feedback to a committer; but in this case the patch is
> stuck and can not be committed. And still no one fills guilty anyone, because
> it is no one fault (aka tragedy of the commons).
I don't really have a pony in this race, but I tend to agree with Cos
on this one.
Evans -- as you said -- it is about human psychology, but that's exactly why
I don't think I have a clear understanding of why RTC provides a better setup.
After all -- we're all committers, so there's no policy that would prevent us
from a physical act of git push'ing. Its all about self control.
And from that standpoint we can have self-imposed RTC today. Suppose
you decide that RTC is better for you -- well then just make it a habit to
ask for review on this list before every single commit you do. See how it
works out for you and either keep doing it or, perhaps, start using your
discretion of not asking when you feel really confident.
This leaves disruptive pushers. Honestly, I haven't seen too much of that
going in so perhaps I don't appreciate the full scope of the problem -- but
it seems to me that RTC won't solve it either.
With all of the above -- what problem is left for us to solve with RTC?
Thanks,
Roman.
Re: CTR vs RTC again [Was: RESULT: [VOTE] Accepting CTR policy for
the project]
Posted by Konstantin Boudnik <co...@apache.org>.
On Wed, Jan 18, 2017 at 01:43PM, Evans Ye wrote:
> > How many of us have asked for the review/feedback and when they did, the
> > feedback wasn't provided?
>
> This is more about psychology I think.
> For example, if a committer provided a patch and seeking for review. Since
> the committer do not highlighting anyone specifically, no one is
> responsible to review it. And anyhow the patch provider(committer) can just
> go ahead and commit it anyway according to CTR. So, no one feels guilty
> about blocking the progress. Therefore no one will review it.
Let me turn this around: under CTR if one is pro-actively seeking for feedback
but no one replies, the code could still be committed. Under RTC no one is
obliged to provide a feedback to a committer; but in this case the patch is
stuck and can not be committed. And still no one fills guilty anyone, because
it is no one fault (aka tragedy of the commons).
> > How many tickets are in the JIRA, before the CTR policy was instituted,
> where the only comment is '+1' or 'LGTM'?
>
> Despite the comment is only +1 or LGTM, but it means a lot:
> 1) Getting positive feedback V.S. no feedback
a mechanical +1 != positive feedback. It is as good a no feedback at all. Only
now there's a chance of dragging the commit forever.
> 2) Policy enforced status sync up V.S. I'm the only one who knew it
Sorry, but I don't believe that enforcing _anything_ via policy really works.
Creating policies only lead to finding of the loopholes.
Cos
> 2017-01-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>
> > so,
> >
> > let me get the presented facts straight:
> > 1 no matter what, under CTR or RTC _all_ contributors patches are
> > supposed to
> > be reviewed/discussed
> > 2 the CTR assumes that a responsible committer would proactively seek the
> > feedback of his peers if such is desired
> > 3 RTC, being a formal requirement to get a +1, is supposedly has an
> > effect on
> > engaging the committers into a wider discussion
> >
> > The #1 stands today and we are reviewing the external contributions (time
> > permits and all). How many of us have asked for the review/feedback and
> > when
> > they did, the feedback wasn't provided? How many tickets are in the JIRA,
> > before the CTR policy was instituted, where the only comment is '+1' or
> > 'LGTM'?
> >
> > So, how a format +1 (which as we know in the past oftentime lead to
> > non-working patches being committed) is an instrument to force committers
> > to
> > seek a feedback?
> >
> > Thanks in advance for any comments on this.
> > Cos
> >
> > On Tue, Jan 17, 2017 at 10:11AM, Andrew Purtell wrote:
> > > I don't think there's a workable halfway here.
> > >
> > > On Tue, Jan 17, 2017 at 9:46 AM, Jay Vyas <ja...@gmail.com>
> > > wrote:
> > >
> > > > Why not CTR into a branch
> > > >
> > > > And RTC in jira that promotes the branch to master?
> > > >
> > > > That way process can continue and those interested can delay promotion
> > to
> > > > master , without delaying other progress
> > > >
> > > > > On Jan 17, 2017, at 12:08 PM, RJ Nowling <rn...@gmail.com> wrote:
> > > > >
> > > > > I agree with Evans.
> > > > >
> > > > > I'll admit that I have been busy with other things (i.e. a new job),
> > > > hence
> > > > > part of my silence in the BigTop community. However, I also agree
> > that
> > > > the
> > > > > required conversation around new commits made it easier to engage
> > with
> > > > > others.
> > > > >
> > > > > The reduced amount of conversation can also hurt new contributors.
> > > > >
> > > > > I believe it is worth discussing returning to the RTC model.
> > > > >
> > > > >> On Sun, Jan 15, 2017 at 3:57 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> > > > >>
> > > > >> Hi Evans,
> > > > >>
> > > > >> thanks for picking up the discussion. I have a rather strong opinion
> > > > >> towards reverting back to RTC, too.
> > > > >>
> > > > >> I am miss the discussion a lot.
> > > > >>
> > > > >> Thanks
> > > > >> Olaf
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>> Am 15.01.2017 um 09:40 schrieb Evans Ye:
> > > > >>>
> > > > >>> Hi Bigtopers,
> > > > >>>
> > > > >>> A year has pasted since we adopted CTR(Commit then Review) model.
> > > > >>> I can see some draw back in this journey, hence I'd like to
> > propose we
> > > > >>> revert the working model back to RTC(Review Then Commit).
> > > > >>>
> > > > >>> Let me list down some known problems I can think of.
> > > > >>> Before I do so, you should know following are not pointing to
> > someone
> > > > >>> particularly. And these may be bias opinions since I'm silencing
> > for a
> > > > >>> long
> > > > >>> while in the community.
> > > > >>>
> > > > >>> a). The community has less conversation because there's no +1
> > required.
> > > > >>> b). Sometimes Committers are working alone, left the contributors
> > out
> > > > side
> > > > >>> of the game.
> > > > >>> c). Communication is the core of the open source community. Without
> > > > this
> > > > >>> it's not fun anymore contributing.
> > > > >>>
> > > > >>> When we adopted CTR, we thought that there will be more time for
> > > > >>> Committers
> > > > >>> to review and interact with contributors, but turns out there's no
> > > > time.
> > > > >>> Maybe we just simply need the guilty back to drive us forward.
> > > > >>>
> > > > >>> Any different voice here?
> > > > >>>
> > > > >>>
> > > > >>> 2015-11-25 4:03 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > > >>>
> > > > >>> With ten +1's; one 0's; and none -1's the [VOTE] has passed. Thanks
> > > > >>>> everyone
> > > > >>>> for casting yours.
> > > > >>>>
> > > > >>>> I will go ahead and update the top-level README file to reflect on
> > > > this.
> > > > >>>>
> > > > >>>> Cheers,
> > > > >>>> Cos
> > > > >>>>
> > > > >>>>> On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
> > > > >>>>>
> > > > >>>>> Using CTR for the Bigtop project has been discussed, experimented
> > > > for a
> > > > >>>>>
> > > > >>>> few
> > > > >>>>
> > > > >>>>> months, and discussed again on this long thread [1] for alomost a
> > > > year
> > > > >>>>>
> > > > >>>> now. The
> > > > >>>>
> > > > >>>>> consensus seems to be reached, but because this is a policy
> > change
> > > > I'd
> > > > >>>>>
> > > > >>>> like to
> > > > >>>>
> > > > >>>>> bring it up for the vote.
> > > > >>>>>
> > > > >>>>> So, please cast your for per the following ledger
> > > > >>>>>
> > > > >>>>> [ ] +1, make the CTR policy permanent for the Bigtop project
> > > > >>>>> [ ] +0, I don't care either way,
> > > > >>>>> [ ] -1, do not make the CTR policy permanent for the Bigtop
> > project
> > > > >>>>>
> > > > >>>> because...
> > > > >>>>
> > > > >>>>>
> > > > >>>>> The vote will be open for at least 72 hours and will be closed on
> > > > >>>>>
> > > > >>>> Tuesday, Nov
> > > > >>>>
> > > > >>>>> 24 at noon PST.
> > > > >>>>>
> > > > >>>>> [1] http://is.gd/TgBovX
> > > > >>>>>
> > > > >>>>> Thanks,
> > > > >>>>> Cos
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > If you are given a choice, you believe you have acted freely. - Raymond
> > > Teller (via Peter Watts)
> >
Re: CTR vs RTC again [Was: RESULT: [VOTE] Accepting CTR policy for
the project]
Posted by Evans Ye <ev...@apache.org>.
> How many of us have asked for the review/feedback and when they did, the
feedback wasn't provided?
This is more about psychology I think.
For example, if a committer provided a patch and seeking for review. Since
the committer do not highlighting anyone specifically, no one is
responsible to review it. And anyhow the patch provider(committer) can just
go ahead and commit it anyway according to CTR. So, no one feels guilty
about blocking the progress. Therefore no one will review it.
> How many tickets are in the JIRA, before the CTR policy was instituted,
where the only comment is '+1' or 'LGTM'?
Despite the comment is only +1 or LGTM, but it means a lot:
1) Getting positive feedback V.S. no feedback
2) Policy enforced status sync up V.S. I'm the only one who knew it
2017-01-18 2:39 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> so,
>
> let me get the presented facts straight:
> 1 no matter what, under CTR or RTC _all_ contributors patches are
> supposed to
> be reviewed/discussed
> 2 the CTR assumes that a responsible committer would proactively seek the
> feedback of his peers if such is desired
> 3 RTC, being a formal requirement to get a +1, is supposedly has an
> effect on
> engaging the committers into a wider discussion
>
> The #1 stands today and we are reviewing the external contributions (time
> permits and all). How many of us have asked for the review/feedback and
> when
> they did, the feedback wasn't provided? How many tickets are in the JIRA,
> before the CTR policy was instituted, where the only comment is '+1' or
> 'LGTM'?
>
> So, how a format +1 (which as we know in the past oftentime lead to
> non-working patches being committed) is an instrument to force committers
> to
> seek a feedback?
>
> Thanks in advance for any comments on this.
> Cos
>
> On Tue, Jan 17, 2017 at 10:11AM, Andrew Purtell wrote:
> > I don't think there's a workable halfway here.
> >
> > On Tue, Jan 17, 2017 at 9:46 AM, Jay Vyas <ja...@gmail.com>
> > wrote:
> >
> > > Why not CTR into a branch
> > >
> > > And RTC in jira that promotes the branch to master?
> > >
> > > That way process can continue and those interested can delay promotion
> to
> > > master , without delaying other progress
> > >
> > > > On Jan 17, 2017, at 12:08 PM, RJ Nowling <rn...@gmail.com> wrote:
> > > >
> > > > I agree with Evans.
> > > >
> > > > I'll admit that I have been busy with other things (i.e. a new job),
> > > hence
> > > > part of my silence in the BigTop community. However, I also agree
> that
> > > the
> > > > required conversation around new commits made it easier to engage
> with
> > > > others.
> > > >
> > > > The reduced amount of conversation can also hurt new contributors.
> > > >
> > > > I believe it is worth discussing returning to the RTC model.
> > > >
> > > >> On Sun, Jan 15, 2017 at 3:57 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> > > >>
> > > >> Hi Evans,
> > > >>
> > > >> thanks for picking up the discussion. I have a rather strong opinion
> > > >> towards reverting back to RTC, too.
> > > >>
> > > >> I am miss the discussion a lot.
> > > >>
> > > >> Thanks
> > > >> Olaf
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> Am 15.01.2017 um 09:40 schrieb Evans Ye:
> > > >>>
> > > >>> Hi Bigtopers,
> > > >>>
> > > >>> A year has pasted since we adopted CTR(Commit then Review) model.
> > > >>> I can see some draw back in this journey, hence I'd like to
> propose we
> > > >>> revert the working model back to RTC(Review Then Commit).
> > > >>>
> > > >>> Let me list down some known problems I can think of.
> > > >>> Before I do so, you should know following are not pointing to
> someone
> > > >>> particularly. And these may be bias opinions since I'm silencing
> for a
> > > >>> long
> > > >>> while in the community.
> > > >>>
> > > >>> a). The community has less conversation because there's no +1
> required.
> > > >>> b). Sometimes Committers are working alone, left the contributors
> out
> > > side
> > > >>> of the game.
> > > >>> c). Communication is the core of the open source community. Without
> > > this
> > > >>> it's not fun anymore contributing.
> > > >>>
> > > >>> When we adopted CTR, we thought that there will be more time for
> > > >>> Committers
> > > >>> to review and interact with contributors, but turns out there's no
> > > time.
> > > >>> Maybe we just simply need the guilty back to drive us forward.
> > > >>>
> > > >>> Any different voice here?
> > > >>>
> > > >>>
> > > >>> 2015-11-25 4:03 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > >>>
> > > >>> With ten +1's; one 0's; and none -1's the [VOTE] has passed. Thanks
> > > >>>> everyone
> > > >>>> for casting yours.
> > > >>>>
> > > >>>> I will go ahead and update the top-level README file to reflect on
> > > this.
> > > >>>>
> > > >>>> Cheers,
> > > >>>> Cos
> > > >>>>
> > > >>>>> On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
> > > >>>>>
> > > >>>>> Using CTR for the Bigtop project has been discussed, experimented
> > > for a
> > > >>>>>
> > > >>>> few
> > > >>>>
> > > >>>>> months, and discussed again on this long thread [1] for alomost a
> > > year
> > > >>>>>
> > > >>>> now. The
> > > >>>>
> > > >>>>> consensus seems to be reached, but because this is a policy
> change
> > > I'd
> > > >>>>>
> > > >>>> like to
> > > >>>>
> > > >>>>> bring it up for the vote.
> > > >>>>>
> > > >>>>> So, please cast your for per the following ledger
> > > >>>>>
> > > >>>>> [ ] +1, make the CTR policy permanent for the Bigtop project
> > > >>>>> [ ] +0, I don't care either way,
> > > >>>>> [ ] -1, do not make the CTR policy permanent for the Bigtop
> project
> > > >>>>>
> > > >>>> because...
> > > >>>>
> > > >>>>>
> > > >>>>> The vote will be open for at least 72 hours and will be closed on
> > > >>>>>
> > > >>>> Tuesday, Nov
> > > >>>>
> > > >>>>> 24 at noon PST.
> > > >>>>>
> > > >>>>> [1] http://is.gd/TgBovX
> > > >>>>>
> > > >>>>> Thanks,
> > > >>>>> Cos
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
>
CTR vs RTC again [Was: RESULT: [VOTE] Accepting CTR policy for the
project]
Posted by Konstantin Boudnik <co...@apache.org>.
so,
let me get the presented facts straight:
1 no matter what, under CTR or RTC _all_ contributors patches are supposed to
be reviewed/discussed
2 the CTR assumes that a responsible committer would proactively seek the
feedback of his peers if such is desired
3 RTC, being a formal requirement to get a +1, is supposedly has an effect on
engaging the committers into a wider discussion
The #1 stands today and we are reviewing the external contributions (time
permits and all). How many of us have asked for the review/feedback and when
they did, the feedback wasn't provided? How many tickets are in the JIRA,
before the CTR policy was instituted, where the only comment is '+1' or
'LGTM'?
So, how a format +1 (which as we know in the past oftentime lead to
non-working patches being committed) is an instrument to force committers to
seek a feedback?
Thanks in advance for any comments on this.
Cos
On Tue, Jan 17, 2017 at 10:11AM, Andrew Purtell wrote:
> I don't think there's a workable halfway here.
>
> On Tue, Jan 17, 2017 at 9:46 AM, Jay Vyas <ja...@gmail.com>
> wrote:
>
> > Why not CTR into a branch
> >
> > And RTC in jira that promotes the branch to master?
> >
> > That way process can continue and those interested can delay promotion to
> > master , without delaying other progress
> >
> > > On Jan 17, 2017, at 12:08 PM, RJ Nowling <rn...@gmail.com> wrote:
> > >
> > > I agree with Evans.
> > >
> > > I'll admit that I have been busy with other things (i.e. a new job),
> > hence
> > > part of my silence in the BigTop community. However, I also agree that
> > the
> > > required conversation around new commits made it easier to engage with
> > > others.
> > >
> > > The reduced amount of conversation can also hurt new contributors.
> > >
> > > I believe it is worth discussing returning to the RTC model.
> > >
> > >> On Sun, Jan 15, 2017 at 3:57 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> > >>
> > >> Hi Evans,
> > >>
> > >> thanks for picking up the discussion. I have a rather strong opinion
> > >> towards reverting back to RTC, too.
> > >>
> > >> I am miss the discussion a lot.
> > >>
> > >> Thanks
> > >> Olaf
> > >>
> > >>
> > >>
> > >>
> > >>> Am 15.01.2017 um 09:40 schrieb Evans Ye:
> > >>>
> > >>> Hi Bigtopers,
> > >>>
> > >>> A year has pasted since we adopted CTR(Commit then Review) model.
> > >>> I can see some draw back in this journey, hence I'd like to propose we
> > >>> revert the working model back to RTC(Review Then Commit).
> > >>>
> > >>> Let me list down some known problems I can think of.
> > >>> Before I do so, you should know following are not pointing to someone
> > >>> particularly. And these may be bias opinions since I'm silencing for a
> > >>> long
> > >>> while in the community.
> > >>>
> > >>> a). The community has less conversation because there's no +1 required.
> > >>> b). Sometimes Committers are working alone, left the contributors out
> > side
> > >>> of the game.
> > >>> c). Communication is the core of the open source community. Without
> > this
> > >>> it's not fun anymore contributing.
> > >>>
> > >>> When we adopted CTR, we thought that there will be more time for
> > >>> Committers
> > >>> to review and interact with contributors, but turns out there's no
> > time.
> > >>> Maybe we just simply need the guilty back to drive us forward.
> > >>>
> > >>> Any different voice here?
> > >>>
> > >>>
> > >>> 2015-11-25 4:03 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >>>
> > >>> With ten +1's; one 0's; and none -1's the [VOTE] has passed. Thanks
> > >>>> everyone
> > >>>> for casting yours.
> > >>>>
> > >>>> I will go ahead and update the top-level README file to reflect on
> > this.
> > >>>>
> > >>>> Cheers,
> > >>>> Cos
> > >>>>
> > >>>>> On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
> > >>>>>
> > >>>>> Using CTR for the Bigtop project has been discussed, experimented
> > for a
> > >>>>>
> > >>>> few
> > >>>>
> > >>>>> months, and discussed again on this long thread [1] for alomost a
> > year
> > >>>>>
> > >>>> now. The
> > >>>>
> > >>>>> consensus seems to be reached, but because this is a policy change
> > I'd
> > >>>>>
> > >>>> like to
> > >>>>
> > >>>>> bring it up for the vote.
> > >>>>>
> > >>>>> So, please cast your for per the following ledger
> > >>>>>
> > >>>>> [ ] +1, make the CTR policy permanent for the Bigtop project
> > >>>>> [ ] +0, I don't care either way,
> > >>>>> [ ] -1, do not make the CTR policy permanent for the Bigtop project
> > >>>>>
> > >>>> because...
> > >>>>
> > >>>>>
> > >>>>> The vote will be open for at least 72 hours and will be closed on
> > >>>>>
> > >>>> Tuesday, Nov
> > >>>>
> > >>>>> 24 at noon PST.
> > >>>>>
> > >>>>> [1] http://is.gd/TgBovX
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Cos
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
Re: RESULT: [VOTE] Accepting CTR policy for the project
Posted by Andrew Purtell <ap...@apache.org>.
I don't think there's a workable halfway here.
On Tue, Jan 17, 2017 at 9:46 AM, Jay Vyas <ja...@gmail.com>
wrote:
> Why not CTR into a branch
>
> And RTC in jira that promotes the branch to master?
>
> That way process can continue and those interested can delay promotion to
> master , without delaying other progress
>
> > On Jan 17, 2017, at 12:08 PM, RJ Nowling <rn...@gmail.com> wrote:
> >
> > I agree with Evans.
> >
> > I'll admit that I have been busy with other things (i.e. a new job),
> hence
> > part of my silence in the BigTop community. However, I also agree that
> the
> > required conversation around new commits made it easier to engage with
> > others.
> >
> > The reduced amount of conversation can also hurt new contributors.
> >
> > I believe it is worth discussing returning to the RTC model.
> >
> >> On Sun, Jan 15, 2017 at 3:57 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> >>
> >> Hi Evans,
> >>
> >> thanks for picking up the discussion. I have a rather strong opinion
> >> towards reverting back to RTC, too.
> >>
> >> I am miss the discussion a lot.
> >>
> >> Thanks
> >> Olaf
> >>
> >>
> >>
> >>
> >>> Am 15.01.2017 um 09:40 schrieb Evans Ye:
> >>>
> >>> Hi Bigtopers,
> >>>
> >>> A year has pasted since we adopted CTR(Commit then Review) model.
> >>> I can see some draw back in this journey, hence I'd like to propose we
> >>> revert the working model back to RTC(Review Then Commit).
> >>>
> >>> Let me list down some known problems I can think of.
> >>> Before I do so, you should know following are not pointing to someone
> >>> particularly. And these may be bias opinions since I'm silencing for a
> >>> long
> >>> while in the community.
> >>>
> >>> a). The community has less conversation because there's no +1 required.
> >>> b). Sometimes Committers are working alone, left the contributors out
> side
> >>> of the game.
> >>> c). Communication is the core of the open source community. Without
> this
> >>> it's not fun anymore contributing.
> >>>
> >>> When we adopted CTR, we thought that there will be more time for
> >>> Committers
> >>> to review and interact with contributors, but turns out there's no
> time.
> >>> Maybe we just simply need the guilty back to drive us forward.
> >>>
> >>> Any different voice here?
> >>>
> >>>
> >>> 2015-11-25 4:03 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >>>
> >>> With ten +1's; one 0's; and none -1's the [VOTE] has passed. Thanks
> >>>> everyone
> >>>> for casting yours.
> >>>>
> >>>> I will go ahead and update the top-level README file to reflect on
> this.
> >>>>
> >>>> Cheers,
> >>>> Cos
> >>>>
> >>>>> On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
> >>>>>
> >>>>> Using CTR for the Bigtop project has been discussed, experimented
> for a
> >>>>>
> >>>> few
> >>>>
> >>>>> months, and discussed again on this long thread [1] for alomost a
> year
> >>>>>
> >>>> now. The
> >>>>
> >>>>> consensus seems to be reached, but because this is a policy change
> I'd
> >>>>>
> >>>> like to
> >>>>
> >>>>> bring it up for the vote.
> >>>>>
> >>>>> So, please cast your for per the following ledger
> >>>>>
> >>>>> [ ] +1, make the CTR policy permanent for the Bigtop project
> >>>>> [ ] +0, I don't care either way,
> >>>>> [ ] -1, do not make the CTR policy permanent for the Bigtop project
> >>>>>
> >>>> because...
> >>>>
> >>>>>
> >>>>> The vote will be open for at least 72 hours and will be closed on
> >>>>>
> >>>> Tuesday, Nov
> >>>>
> >>>>> 24 at noon PST.
> >>>>>
> >>>>> [1] http://is.gd/TgBovX
> >>>>>
> >>>>> Thanks,
> >>>>> Cos
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: RESULT: [VOTE] Accepting CTR policy for the project
Posted by Jay Vyas <ja...@gmail.com>.
Why not CTR into a branch
And RTC in jira that promotes the branch to master?
That way process can continue and those interested can delay promotion to master , without delaying other progress
> On Jan 17, 2017, at 12:08 PM, RJ Nowling <rn...@gmail.com> wrote:
>
> I agree with Evans.
>
> I'll admit that I have been busy with other things (i.e. a new job), hence
> part of my silence in the BigTop community. However, I also agree that the
> required conversation around new commits made it easier to engage with
> others.
>
> The reduced amount of conversation can also hurt new contributors.
>
> I believe it is worth discussing returning to the RTC model.
>
>> On Sun, Jan 15, 2017 at 3:57 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
>>
>> Hi Evans,
>>
>> thanks for picking up the discussion. I have a rather strong opinion
>> towards reverting back to RTC, too.
>>
>> I am miss the discussion a lot.
>>
>> Thanks
>> Olaf
>>
>>
>>
>>
>>> Am 15.01.2017 um 09:40 schrieb Evans Ye:
>>>
>>> Hi Bigtopers,
>>>
>>> A year has pasted since we adopted CTR(Commit then Review) model.
>>> I can see some draw back in this journey, hence I'd like to propose we
>>> revert the working model back to RTC(Review Then Commit).
>>>
>>> Let me list down some known problems I can think of.
>>> Before I do so, you should know following are not pointing to someone
>>> particularly. And these may be bias opinions since I'm silencing for a
>>> long
>>> while in the community.
>>>
>>> a). The community has less conversation because there's no +1 required.
>>> b). Sometimes Committers are working alone, left the contributors out side
>>> of the game.
>>> c). Communication is the core of the open source community. Without this
>>> it's not fun anymore contributing.
>>>
>>> When we adopted CTR, we thought that there will be more time for
>>> Committers
>>> to review and interact with contributors, but turns out there's no time.
>>> Maybe we just simply need the guilty back to drive us forward.
>>>
>>> Any different voice here?
>>>
>>>
>>> 2015-11-25 4:03 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>>>
>>> With ten +1's; one 0's; and none -1's the [VOTE] has passed. Thanks
>>>> everyone
>>>> for casting yours.
>>>>
>>>> I will go ahead and update the top-level README file to reflect on this.
>>>>
>>>> Cheers,
>>>> Cos
>>>>
>>>>> On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
>>>>>
>>>>> Using CTR for the Bigtop project has been discussed, experimented for a
>>>>>
>>>> few
>>>>
>>>>> months, and discussed again on this long thread [1] for alomost a year
>>>>>
>>>> now. The
>>>>
>>>>> consensus seems to be reached, but because this is a policy change I'd
>>>>>
>>>> like to
>>>>
>>>>> bring it up for the vote.
>>>>>
>>>>> So, please cast your for per the following ledger
>>>>>
>>>>> [ ] +1, make the CTR policy permanent for the Bigtop project
>>>>> [ ] +0, I don't care either way,
>>>>> [ ] -1, do not make the CTR policy permanent for the Bigtop project
>>>>>
>>>> because...
>>>>
>>>>>
>>>>> The vote will be open for at least 72 hours and will be closed on
>>>>>
>>>> Tuesday, Nov
>>>>
>>>>> 24 at noon PST.
>>>>>
>>>>> [1] http://is.gd/TgBovX
>>>>>
>>>>> Thanks,
>>>>> Cos
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
Re: RESULT: [VOTE] Accepting CTR policy for the project
Posted by RJ Nowling <rn...@gmail.com>.
I agree with Evans.
I'll admit that I have been busy with other things (i.e. a new job), hence
part of my silence in the BigTop community. However, I also agree that the
required conversation around new commits made it easier to engage with
others.
The reduced amount of conversation can also hurt new contributors.
I believe it is worth discussing returning to the RTC model.
On Sun, Jan 15, 2017 at 3:57 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> Hi Evans,
>
> thanks for picking up the discussion. I have a rather strong opinion
> towards reverting back to RTC, too.
>
> I am miss the discussion a lot.
>
> Thanks
> Olaf
>
>
>
>
> Am 15.01.2017 um 09:40 schrieb Evans Ye:
>
>> Hi Bigtopers,
>>
>> A year has pasted since we adopted CTR(Commit then Review) model.
>> I can see some draw back in this journey, hence I'd like to propose we
>> revert the working model back to RTC(Review Then Commit).
>>
>> Let me list down some known problems I can think of.
>> Before I do so, you should know following are not pointing to someone
>> particularly. And these may be bias opinions since I'm silencing for a
>> long
>> while in the community.
>>
>> a). The community has less conversation because there's no +1 required.
>> b). Sometimes Committers are working alone, left the contributors out side
>> of the game.
>> c). Communication is the core of the open source community. Without this
>> it's not fun anymore contributing.
>>
>> When we adopted CTR, we thought that there will be more time for
>> Committers
>> to review and interact with contributors, but turns out there's no time.
>> Maybe we just simply need the guilty back to drive us forward.
>>
>> Any different voice here?
>>
>>
>> 2015-11-25 4:03 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>>
>> With ten +1's; one 0's; and none -1's the [VOTE] has passed. Thanks
>>> everyone
>>> for casting yours.
>>>
>>> I will go ahead and update the top-level README file to reflect on this.
>>>
>>> Cheers,
>>> Cos
>>>
>>> On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
>>>
>>>> Using CTR for the Bigtop project has been discussed, experimented for a
>>>>
>>> few
>>>
>>>> months, and discussed again on this long thread [1] for alomost a year
>>>>
>>> now. The
>>>
>>>> consensus seems to be reached, but because this is a policy change I'd
>>>>
>>> like to
>>>
>>>> bring it up for the vote.
>>>>
>>>> So, please cast your for per the following ledger
>>>>
>>>> [ ] +1, make the CTR policy permanent for the Bigtop project
>>>> [ ] +0, I don't care either way,
>>>> [ ] -1, do not make the CTR policy permanent for the Bigtop project
>>>>
>>> because...
>>>
>>>>
>>>> The vote will be open for at least 72 hours and will be closed on
>>>>
>>> Tuesday, Nov
>>>
>>>> 24 at noon PST.
>>>>
>>>> [1] http://is.gd/TgBovX
>>>>
>>>> Thanks,
>>>> Cos
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
Re: RESULT: [VOTE] Accepting CTR policy for the project
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Evans,
thanks for picking up the discussion. I have a rather strong opinion
towards reverting back to RTC, too.
I am miss the discussion a lot.
Thanks
Olaf
Am 15.01.2017 um 09:40 schrieb Evans Ye:
> Hi Bigtopers,
>
> A year has pasted since we adopted CTR(Commit then Review) model.
> I can see some draw back in this journey, hence I'd like to propose we
> revert the working model back to RTC(Review Then Commit).
>
> Let me list down some known problems I can think of.
> Before I do so, you should know following are not pointing to someone
> particularly. And these may be bias opinions since I'm silencing for a long
> while in the community.
>
> a). The community has less conversation because there's no +1 required.
> b). Sometimes Committers are working alone, left the contributors out side
> of the game.
> c). Communication is the core of the open source community. Without this
> it's not fun anymore contributing.
>
> When we adopted CTR, we thought that there will be more time for Committers
> to review and interact with contributors, but turns out there's no time.
> Maybe we just simply need the guilty back to drive us forward.
>
> Any different voice here?
>
>
> 2015-11-25 4:03 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>
>> With ten +1's; one 0's; and none -1's the [VOTE] has passed. Thanks
>> everyone
>> for casting yours.
>>
>> I will go ahead and update the top-level README file to reflect on this.
>>
>> Cheers,
>> Cos
>>
>> On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
>>> Using CTR for the Bigtop project has been discussed, experimented for a
>> few
>>> months, and discussed again on this long thread [1] for alomost a year
>> now. The
>>> consensus seems to be reached, but because this is a policy change I'd
>> like to
>>> bring it up for the vote.
>>>
>>> So, please cast your for per the following ledger
>>>
>>> [ ] +1, make the CTR policy permanent for the Bigtop project
>>> [ ] +0, I don't care either way,
>>> [ ] -1, do not make the CTR policy permanent for the Bigtop project
>> because...
>>>
>>> The vote will be open for at least 72 hours and will be closed on
>> Tuesday, Nov
>>> 24 at noon PST.
>>>
>>> [1] http://is.gd/TgBovX
>>>
>>> Thanks,
>>> Cos
>>>
>>>
>>>
>>>
>>
>>
>>
>
Re: RESULT: [VOTE] Accepting CTR policy for the project
Posted by Evans Ye <ev...@apache.org>.
Hi Bigtopers,
A year has pasted since we adopted CTR(Commit then Review) model.
I can see some draw back in this journey, hence I'd like to propose we
revert the working model back to RTC(Review Then Commit).
Let me list down some known problems I can think of.
Before I do so, you should know following are not pointing to someone
particularly. And these may be bias opinions since I'm silencing for a long
while in the community.
a). The community has less conversation because there's no +1 required.
b). Sometimes Committers are working alone, left the contributors out side
of the game.
c). Communication is the core of the open source community. Without this
it's not fun anymore contributing.
When we adopted CTR, we thought that there will be more time for Committers
to review and interact with contributors, but turns out there's no time.
Maybe we just simply need the guilty back to drive us forward.
Any different voice here?
2015-11-25 4:03 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> With ten +1's; one 0's; and none -1's the [VOTE] has passed. Thanks
> everyone
> for casting yours.
>
> I will go ahead and update the top-level README file to reflect on this.
>
> Cheers,
> Cos
>
> On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
> > Using CTR for the Bigtop project has been discussed, experimented for a
> few
> > months, and discussed again on this long thread [1] for alomost a year
> now. The
> > consensus seems to be reached, but because this is a policy change I'd
> like to
> > bring it up for the vote.
> >
> > So, please cast your for per the following ledger
> >
> > [ ] +1, make the CTR policy permanent for the Bigtop project
> > [ ] +0, I don't care either way,
> > [ ] -1, do not make the CTR policy permanent for the Bigtop project
> because...
> >
> > The vote will be open for at least 72 hours and will be closed on
> Tuesday, Nov
> > 24 at noon PST.
> >
> > [1] http://is.gd/TgBovX
> >
> > Thanks,
> > Cos
> >
> >
> >
> >
>
>
>
RESULT: [VOTE] Accepting CTR policy for the project
Posted by Konstantin Boudnik <co...@apache.org>.
With ten +1's; one 0's; and none -1's the [VOTE] has passed. Thanks everyone
for casting yours.
I will go ahead and update the top-level README file to reflect on this.
Cheers,
Cos
On Sat, Nov 21, 2015 at 11:34AM, Konstantin Boudnik wrote:
> Using CTR for the Bigtop project has been discussed, experimented for a few
> months, and discussed again on this long thread [1] for alomost a year now. The
> consensus seems to be reached, but because this is a policy change I'd like to
> bring it up for the vote.
>
> So, please cast your for per the following ledger
>
> [ ] +1, make the CTR policy permanent for the Bigtop project
> [ ] +0, I don't care either way,
> [ ] -1, do not make the CTR policy permanent for the Bigtop project because...
>
> The vote will be open for at least 72 hours and will be closed on Tuesday, Nov
> 24 at noon PST.
>
> [1] http://is.gd/TgBovX
>
> Thanks,
> Cos
>
>
>
>
Re: [VOTE] Accepting CTR policy for the project
Posted by Evans Ye <ev...@apache.org>.
+1
2015-11-22 12:28 GMT+08:00 Bruno Mahé <bm...@apache.org>:
> +0.
>
> Thanks,
> Bruno
>
>
> On 11/21/2015 11:34 AM, Konstantin Boudnik wrote:
>
>> Using CTR for the Bigtop project has been discussed, experimented for a
>> few
>> months, and discussed again on this long thread [1] for alomost a year
>> now. The
>> consensus seems to be reached, but because this is a policy change I'd
>> like to
>> bring it up for the vote.
>>
>> So, please cast your for per the following ledger
>>
>> [ ] +1, make the CTR policy permanent for the Bigtop project
>> [ ] +0, I don't care either way,
>> [ ] -1, do not make the CTR policy permanent for the Bigtop project
>> because...
>>
>> The vote will be open for at least 72 hours and will be closed on
>> Tuesday, Nov
>> 24 at noon PST.
>>
>> [1] http://is.gd/TgBovX
>>
>> Thanks,
>> Cos
>>
>>
>>
>>
>>
>
Re: [VOTE] Accepting CTR policy for the project
Posted by Bruno Mahé <bm...@apache.org>.
+0.
Thanks,
Bruno
On 11/21/2015 11:34 AM, Konstantin Boudnik wrote:
> Using CTR for the Bigtop project has been discussed, experimented for a few
> months, and discussed again on this long thread [1] for alomost a year now. The
> consensus seems to be reached, but because this is a policy change I'd like to
> bring it up for the vote.
>
> So, please cast your for per the following ledger
>
> [ ] +1, make the CTR policy permanent for the Bigtop project
> [ ] +0, I don't care either way,
> [ ] -1, do not make the CTR policy permanent for the Bigtop project because...
>
> The vote will be open for at least 72 hours and will be closed on Tuesday, Nov
> 24 at noon PST.
>
> [1] http://is.gd/TgBovX
>
> Thanks,
> Cos
>
>
>
>
Re: [VOTE] Accepting CTR policy for the project
Posted by Peter Linnell <pl...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 21 Nov 2015 11:34:59 -0800
Konstantin Boudnik <co...@apache.org> wrote:
+1
> Using CTR for the Bigtop project has been discussed, experimented for
> a few months, and discussed again on this long thread [1] for alomost
> a year now. The consensus seems to be reached, but because this is a
> policy change I'd like to bring it up for the vote.
>
> So, please cast your for per the following ledger
>
> [ ] +1, make the CTR policy permanent for the Bigtop project
> [ ] +0, I don't care either way,
> [ ] -1, do not make the CTR policy permanent for the Bigtop project
> because...
>
> The vote will be open for at least 72 hours and will be closed on
> Tuesday, Nov 24 at noon PST.
>
> [1] http://is.gd/TgBovX
>
> Thanks,
> Cos
>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlZRSKQACgkQ73uV5/YBZtoQGQCePsGZyGdTyvGssVUO2y6DngoG
ZuUAnA7zHQnhpMcSSaH5Y/yV9kS03/Xj
=vo/Z
-----END PGP SIGNATURE-----