[VOTE] Improve Ignite GIT Process

[Dmitriy Setrakyan <ds...@apache.org>]

Let's have a vote on the GIT structure proposed by the community (mainly
Brane and Cos).

- Master should become the development branch for the next release.
- All individual ticket branches should be created off of the master branch.
- When we are working on the 2 releases in parallel, we should create a
special release branch and merge it back to master, once the master branch
has been released.
- Master gets tagged for every release.
- Same CI rules as we have now apply - all CI tests must pass before the
merge of ticket branches to the master branch.

Please vote:
+1 - I agree with the new structure
0 - don't care
-1 - I disagree (explain why).

Re: [VOTE] Improve Ignite GIT Process

[Konstantin Boudnik <co...@apache.org>]

I'm with Brane on this one (unlike git cherry picking ;). Vote is a tool to record a consensus reached via a discussion/collaboration. Apache isn't a democracy where majority rules; hence voting isn't a decision-making tool.

Cos

On June 7, 2015 6:02:31 PM GMT+03:00, "Branko Čibej" <br...@apache.org> wrote:
>On 07.06.2015 16:15, Dmitriy Setrakyan wrote:
>> How do we reach consensus without a vote? I thought vote will
>encourage
>> everyone to participate and provide opinion.
>>
>> I can cancel the vote, but so far I have heard no objections to the
>newly
>> proposed structure. Does it mean we have a consensus?
>
>If you need a vote, you don't have consensus. If you have consensus,
>then nobody explicitly disagrees. The most frequent consensus-building
>process at the ASF is the "silent consensus": Someone makes a proposal,
>and if no-one objects within a reasonable time (e.g., at  least 72
>hours
>but can be longer especially during are week-ends or holidays).
>
>There are only two cases where voting is mandatory: vetting a release
>and adding a PMC member. In both cases the formal vote is essentially a
>legal requirement. Even in these cases, if you suspect that a vote is
>likely to fail, it's better to not vote at all and discuss alternatives
>instead.
>
>You'll often see the motto "community over code" around here; but it
>should also be "community over process" because using procedural tools
>to override lack of consensus is a really bad thing.
>
>
>To get back on topic: I suggest you (or someone) writes up a document,
>as a wiki page for example, that concisely describes the CM process
>we've been discussing in this thread; then just write a mail to dev@
>and
>ask for comments. Eventually you'll get a more or less final version of
>the doc without having to vote at all. Unlike voting, with gives you
>all-or-nothing result, in this way you'll get a document that keeps
>evolving as your needs change. If you voted instead, you'd also have to
>vote for any change to the doc ... which is weird, right? :)
>
>-- Brane
>
>
>On Sun, Jun 7, 2015 at 5:10 PM, Branko Čibej <br...@apache.org> wrote:
>>> On 07.06.2015 15:50, Dmitriy Setrakyan wrote:
>>>> Let's have a vote on the GIT structure proposed by the community
>(mainly
>>>> Brane and Cos).
>>> Stop right there. Voting makes no sense at all. Discuss and reach
>>> consensus instead.
>>>
>>> Voting should never be used as a decision-making tool; it's an
>>> indication that the community can't agree on anything and resorts to
>>> majority rule instead of consensus rule.
>>>
>>> -- Brane
>>>
>>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [VOTE] Improve Ignite GIT Process

[Branko Čibej <br...@apache.org>]

On 07.06.2015 16:15, Dmitriy Setrakyan wrote:
> How do we reach consensus without a vote? I thought vote will encourage
> everyone to participate and provide opinion.
>
> I can cancel the vote, but so far I have heard no objections to the newly
> proposed structure. Does it mean we have a consensus?

If you need a vote, you don't have consensus. If you have consensus,
then nobody explicitly disagrees. The most frequent consensus-building
process at the ASF is the "silent consensus": Someone makes a proposal,
and if no-one objects within a reasonable time (e.g., at  least 72 hours
but can be longer especially during are week-ends or holidays).

There are only two cases where voting is mandatory: vetting a release
and adding a PMC member. In both cases the formal vote is essentially a
legal requirement. Even in these cases, if you suspect that a vote is
likely to fail, it's better to not vote at all and discuss alternatives
instead.

You'll often see the motto "community over code" around here; but it
should also be "community over process" because using procedural tools
to override lack of consensus is a really bad thing.


To get back on topic: I suggest you (or someone) writes up a document,
as a wiki page for example, that concisely describes the CM process
we've been discussing in this thread; then just write a mail to dev@ and
ask for comments. Eventually you'll get a more or less final version of
the doc without having to vote at all. Unlike voting, with gives you
all-or-nothing result, in this way you'll get a document that keeps
evolving as your needs change. If you voted instead, you'd also have to
vote for any change to the doc ... which is weird, right? :)

-- Brane


On Sun, Jun 7, 2015 at 5:10 PM, Branko Čibej <br...@apache.org> wrote:
>> On 07.06.2015 15:50, Dmitriy Setrakyan wrote:
>>> Let's have a vote on the GIT structure proposed by the community (mainly
>>> Brane and Cos).
>> Stop right there. Voting makes no sense at all. Discuss and reach
>> consensus instead.
>>
>> Voting should never be used as a decision-making tool; it's an
>> indication that the community can't agree on anything and resorts to
>> majority rule instead of consensus rule.
>>
>> -- Brane
>>
>>

Re: [VOTE] Improve Ignite GIT Process

[Atri Sharma <at...@gmail.com>]

I think it is the standard structure to be followed and given that many
open source projects follow it, we can safely assume that we will be stable
on it.
On 7 Jun 2015 19:46, "Dmitriy Setrakyan" <ds...@apache.org> wrote:

> How do we reach consensus without a vote? I thought vote will encourage
> everyone to participate and provide opinion.
>
> I can cancel the vote, but so far I have heard no objections to the newly
> proposed structure. Does it mean we have a consensus?
>
> D.
>
> On Sun, Jun 7, 2015 at 5:10 PM, Branko Čibej <br...@apache.org> wrote:
>
> > On 07.06.2015 15:50, Dmitriy Setrakyan wrote:
> > > Let's have a vote on the GIT structure proposed by the community
> (mainly
> > > Brane and Cos).
> >
> > Stop right there. Voting makes no sense at all. Discuss and reach
> > consensus instead.
> >
> > Voting should never be used as a decision-making tool; it's an
> > indication that the community can't agree on anything and resorts to
> > majority rule instead of consensus rule.
> >
> > -- Brane
> >
> >
>

Re: [VOTE] Improve Ignite GIT Process

[Dmitriy Setrakyan <ds...@apache.org>]

How do we reach consensus without a vote? I thought vote will encourage
everyone to participate and provide opinion.

I can cancel the vote, but so far I have heard no objections to the newly
proposed structure. Does it mean we have a consensus?

D.

On Sun, Jun 7, 2015 at 5:10 PM, Branko Čibej <br...@apache.org> wrote:

> On 07.06.2015 15:50, Dmitriy Setrakyan wrote:
> > Let's have a vote on the GIT structure proposed by the community (mainly
> > Brane and Cos).
>
> Stop right there. Voting makes no sense at all. Discuss and reach
> consensus instead.
>
> Voting should never be used as a decision-making tool; it's an
> indication that the community can't agree on anything and resorts to
> majority rule instead of consensus rule.
>
> -- Brane
>
>

Re: [VOTE] Improve Ignite GIT Process

[Branko Čibej <br...@apache.org>]

On 11.06.2015 09:37, Valentin Kulichenko wrote:
> Actually this silence is my main concern here :)
>
> We're going the change the process. And everyone in the community has to
> move to the new process at the same time. I have nothing against consensus
> concept, but IMHO there should be some formal indicator. Such a vote (if we
> do not apply majority rules to it) can be one of them - when the vote is
> closed, decision is made. Are there other options?

Silence is no different than not casting a vote. It either means "I
agree" or "I can't even be bothered to read the mailing lists", that's
why we us the at-least-72-hours rule, which is not a rule but a
guideline and it makes sense to extend the deadline for important decisions.

In either case, it's up to each individual contributor to conform to the
process that the community decided to implement. If at a later date you
find, through code/commit review (which you should be doing anyway!)
that someone isn't following the process, you gently remind them about
that, point to the documentation and ask them to follow it.

I'll remind you again that this is a community of volunteers, not a
hierarchically structured corporation.

-- Brane


> On Jun 11, 2015 12:03 AM, "Branko Čibej" <br...@apache.org> wrote:
>
>> On 11.06.2015 01:47, Valentin Kulichenko wrote:
>>> Hmm. I'm not sure I understand. As far as I understand, any vote here
>>> is unanimous, but not majority. I.e., if anyone in community has
>>> objections, vote is declined (already not a democracy, right? :) ). If
>> so,
>>> I really don't see any difference between "consensus is recorded by no
>>> objections
>>> being raised" and "consensus is recorded by the vote being passed".
>> See again re "silent consensus". It's an informal process. Voting is
>> formal and by definition implies that the majority rules. Consensus
>> implies something else entirely. A -1 vote can be overridden by others.
>> An objection during silent consensus process cannot.
>>
>> -- Brane
>>
>>

Re: [VOTE] Improve Ignite GIT Process

[Konstantin Boudnik <co...@apache.org>]

On June 11, 2015 10:37:22 AM GMT+03:00, Valentin Kulichenko <va...@gmail.com> wrote:
>Actually this silence is my main concern here :)
>
>We're going the change the process. And everyone in the community has
>to
>move to the new process at the same time. I have nothing against
>consensus
>concept, but IMHO there should be some formal indicator. Such a vote
>(if we
>do not apply majority rules to it) can be one of them - when the vote
>is
>closed, decision is made. Are there other options?

It might sound like i'm somewhat reverting from what I said earlier and it is ;) After quite a bit of consideration I'm going to fully back Brane's stance on that. If needed results were achieved through the 'silent 
consensus' why doing an extra effort and run a vote? The formal indicator would be a change in the project/design documentation, or wiki, or code.

This is true Dao of open source: you do less to actually achieve more! Just go with flow - don't build new procedural barriers if you can do without them. 

Cos

>-Val
>On Jun 11, 2015 12:03 AM, "Branko Čibej" <br...@apache.org> wrote:
>
>> On 11.06.2015 01:47, Valentin Kulichenko wrote:
>> > Hmm. I'm not sure I understand. As far as I understand, any vote
>here
>> > is unanimous, but not majority. I.e., if anyone in community has
>> > objections, vote is declined (already not a democracy, right? :) ).
>If
>> so,
>> > I really don't see any difference between "consensus is recorded by
>no
>> > objections
>> > being raised" and "consensus is recorded by the vote being passed".
>>
>> See again re "silent consensus". It's an informal process. Voting is
>> formal and by definition implies that the majority rules. Consensus
>> implies something else entirely. A -1 vote can be overridden by
>others.
>> An objection during silent consensus process cannot.
>>
>> -- Brane
>>
>>

Re: [VOTE] Improve Ignite GIT Process

[Branko Čibej <br...@apache.org>]

On 11.06.2015 09:39, Dmitriy Setrakyan wrote:
> I tend to agree with Valentin. This is a change that will affect the whole
> project, and one of the cases where voting makes sense in my view.

So what if it affects the whole project? Many code changes are like
that, and you for sure are not going to vote on them in advance.

What do you intend to do if someone votes -1? Or if somebody doesn't
vote? Are you going to declare that the vote failed and stay with the
current process? Or are you going to ignore the -1 vote and implement
the new process despite the fact that you're clearly going to piss off
someone who actually took the time to voice their opinion?

-- Brane


>
> D.
>
> On Thu, Jun 11, 2015 at 8:37 AM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
>> Actually this silence is my main concern here :)
>>
>> We're going the change the process. And everyone in the community has to
>> move to the new process at the same time. I have nothing against consensus
>> concept, but IMHO there should be some formal indicator. Such a vote (if we
>> do not apply majority rules to it) can be one of them - when the vote is
>> closed, decision is made. Are there other options?
>>
>> -Val
>> On Jun 11, 2015 12:03 AM, "Branko Čibej" <br...@apache.org> wrote:
>>
>>> On 11.06.2015 01:47, Valentin Kulichenko wrote:
>>>> Hmm. I'm not sure I understand. As far as I understand, any vote here
>>>> is unanimous, but not majority. I.e., if anyone in community has
>>>> objections, vote is declined (already not a democracy, right? :) ). If
>>> so,
>>>> I really don't see any difference between "consensus is recorded by no
>>>> objections
>>>> being raised" and "consensus is recorded by the vote being passed".
>>> See again re "silent consensus". It's an informal process. Voting is
>>> formal and by definition implies that the majority rules. Consensus
>>> implies something else entirely. A -1 vote can be overridden by others.
>>> An objection during silent consensus process cannot.
>>>
>>> -- Brane
>>>
>>>

Re: [VOTE] Improve Ignite GIT Process

[Dmitriy Setrakyan <ds...@apache.org>]

I tend to agree with Valentin. This is a change that will affect the whole
project, and one of the cases where voting makes sense in my view.

D.

On Thu, Jun 11, 2015 at 8:37 AM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> Actually this silence is my main concern here :)
>
> We're going the change the process. And everyone in the community has to
> move to the new process at the same time. I have nothing against consensus
> concept, but IMHO there should be some formal indicator. Such a vote (if we
> do not apply majority rules to it) can be one of them - when the vote is
> closed, decision is made. Are there other options?
>
> -Val
> On Jun 11, 2015 12:03 AM, "Branko Čibej" <br...@apache.org> wrote:
>
> > On 11.06.2015 01:47, Valentin Kulichenko wrote:
> > > Hmm. I'm not sure I understand. As far as I understand, any vote here
> > > is unanimous, but not majority. I.e., if anyone in community has
> > > objections, vote is declined (already not a democracy, right? :) ). If
> > so,
> > > I really don't see any difference between "consensus is recorded by no
> > > objections
> > > being raised" and "consensus is recorded by the vote being passed".
> >
> > See again re "silent consensus". It's an informal process. Voting is
> > formal and by definition implies that the majority rules. Consensus
> > implies something else entirely. A -1 vote can be overridden by others.
> > An objection during silent consensus process cannot.
> >
> > -- Brane
> >
> >
>

Re: [VOTE] Improve Ignite GIT Process

[Valentin Kulichenko <va...@gmail.com>]

Actually this silence is my main concern here :)

We're going the change the process. And everyone in the community has to
move to the new process at the same time. I have nothing against consensus
concept, but IMHO there should be some formal indicator. Such a vote (if we
do not apply majority rules to it) can be one of them - when the vote is
closed, decision is made. Are there other options?

-Val
On Jun 11, 2015 12:03 AM, "Branko Čibej" <br...@apache.org> wrote:

> On 11.06.2015 01:47, Valentin Kulichenko wrote:
> > Hmm. I'm not sure I understand. As far as I understand, any vote here
> > is unanimous, but not majority. I.e., if anyone in community has
> > objections, vote is declined (already not a democracy, right? :) ). If
> so,
> > I really don't see any difference between "consensus is recorded by no
> > objections
> > being raised" and "consensus is recorded by the vote being passed".
>
> See again re "silent consensus". It's an informal process. Voting is
> formal and by definition implies that the majority rules. Consensus
> implies something else entirely. A -1 vote can be overridden by others.
> An objection during silent consensus process cannot.
>
> -- Brane
>
>

Re: [VOTE] Improve Ignite GIT Process

[Branko Čibej <br...@apache.org>]

On 11.06.2015 01:47, Valentin Kulichenko wrote:
> Hmm. I'm not sure I understand. As far as I understand, any vote here
> is unanimous, but not majority. I.e., if anyone in community has
> objections, vote is declined (already not a democracy, right? :) ). If so,
> I really don't see any difference between "consensus is recorded by no
> objections
> being raised" and "consensus is recorded by the vote being passed".

See again re "silent consensus". It's an informal process. Voting is
formal and by definition implies that the majority rules. Consensus
implies something else entirely. A -1 vote can be overridden by others.
An objection during silent consensus process cannot.

-- Brane

Re: [VOTE] Improve Ignite GIT Process

[Valentin Kulichenko <va...@gmail.com>]

Hmm. I'm not sure I understand. As far as I understand, any vote here
is unanimous, but not majority. I.e., if anyone in community has
objections, vote is declined (already not a democracy, right? :) ). If so,
I really don't see any difference between "consensus is recorded by no
objections
being raised" and "consensus is recorded by the vote being passed".

There should be a moment of time when the change in the process is applied.
What if I really don't care how branching is organized, but just want to
write code? In this case I would like to have the process documented and,
if there are any changes, to know when they come into play. IMHO, closed
vote can be a good formal indicator for this.

Are you against any formal procedures per se, or I'm missing something in
this particular case?

-Val

On Mon, Jun 8, 2015 at 6:27 AM, Konstantin Boudnik <co...@boudnik.org> wrote:

>
> --
> Regards,
>   Cos
>
> On June 8, 2015 1:20:56 PM GMT+03:00, "Branko Čibej" <br...@apache.org>
> wrote:
> >On 07.06.2015 18:00, Konstantin Boudnik wrote:
> >> I'm with Brane on this one (unlike git cherry picking ;). Vote is a
> >tool to
> >> record a consensus reached via a discussion/collaboration.
> >
> >No, it's not, that's exactly my point: Consensus is recorded by no
> >objections being raised on the appropriate mailing list (dev@ for
> >public
> >discussions) during a reasonable amount of time. You do *not* vote to
> >"record consensus". Voting is a formal procedure that is either
> >mandated
> >by legal requirements (e.g., for releases) or used when consensus
> >cannot
> >be reached -- and in the latter case, it should not be used because ASF
> >communities do not operate by majority rule.
>
> That's exactly what I said: it isn't democracy (sorry for using this word
> in a polite company).
>
> >Cos, I expected better from you. :)
>
> Sorry to disappoint you ;)
>

Re: [VOTE] Improve Ignite GIT Process

[Konstantin Boudnik <co...@boudnik.org>]

-- 
Regards,
  Cos

On June 8, 2015 1:20:56 PM GMT+03:00, "Branko Čibej" <br...@apache.org> wrote:
>On 07.06.2015 18:00, Konstantin Boudnik wrote:
>> I'm with Brane on this one (unlike git cherry picking ;). Vote is a
>tool to
>> record a consensus reached via a discussion/collaboration.
>
>No, it's not, that's exactly my point: Consensus is recorded by no
>objections being raised on the appropriate mailing list (dev@ for
>public
>discussions) during a reasonable amount of time. You do *not* vote to
>"record consensus". Voting is a formal procedure that is either
>mandated
>by legal requirements (e.g., for releases) or used when consensus
>cannot
>be reached -- and in the latter case, it should not be used because ASF
>communities do not operate by majority rule.

That's exactly what I said: it isn't democracy (sorry for using this word in a polite company).

>Cos, I expected better from you. :)

Sorry to disappoint you ;)

Re: [VOTE] Improve Ignite GIT Process

[Branko Čibej <br...@apache.org>]

On 07.06.2015 18:00, Konstantin Boudnik wrote:
> I'm with Brane on this one (unlike git cherry picking ;). Vote is a tool to
> record a consensus reached via a discussion/collaboration.

No, it's not, that's exactly my point: Consensus is recorded by no
objections being raised on the appropriate mailing list (dev@ for public
discussions) during a reasonable amount of time. You do *not* vote to
"record consensus". Voting is a formal procedure that is either mandated
by legal requirements (e.g., for releases) or used when consensus cannot
be reached -- and in the latter case, it should not be used because ASF
communities do not operate by majority rule.

Cos, I expected better from you. :)

-- Brane

Re: [VOTE] Improve Ignite GIT Process

[Konstantin Boudnik <co...@apache.org>]

I'm with Brane on this one (unlike git cherry picking ;). Vote is a tool to
record a consensus reached via a discussion/collaboration. Apache isn't a
democracy where majority rules; hence voting isn't a decision-making tool.

Cos

On Sun, Jun 07, 2015 at 04:10PM, Branko Čibej wrote:
> On 07.06.2015 15:50, Dmitriy Setrakyan wrote:
> > Let's have a vote on the GIT structure proposed by the community (mainly
> > Brane and Cos).
> 
> Stop right there. Voting makes no sense at all. Discuss and reach
> consensus instead.
> 
> Voting should never be used as a decision-making tool; it's an
> indication that the community can't agree on anything and resorts to
> majority rule instead of consensus rule.
> 
> -- Brane
> 

Re: [VOTE] Improve Ignite GIT Process

[Branko Čibej <br...@apache.org>]

On 07.06.2015 15:50, Dmitriy Setrakyan wrote:
> Let's have a vote on the GIT structure proposed by the community (mainly
> Brane and Cos).

Stop right there. Voting makes no sense at all. Discuss and reach
consensus instead.

Voting should never be used as a decision-making tool; it's an
indication that the community can't agree on anything and resorts to
majority rule instead of consensus rule.

-- Brane

Re: [VOTE] Improve Ignite GIT Process

[Nikita Ivanov <ni...@gmail.com>]

+1

--
Nikita Ivanov


On Sun, Jun 7, 2015 at 6:50 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> Let's have a vote on the GIT structure proposed by the community (mainly
> Brane and Cos).
>
> - Master should become the development branch for the next release.
> - All individual ticket branches should be created off of the master
> branch.
> - When we are working on the 2 releases in parallel, we should create a
> special release branch and merge it back to master, once the master branch
> has been released.
> - Master gets tagged for every release.
> - Same CI rules as we have now apply - all CI tests must pass before the
> merge of ticket branches to the master branch.
>
> Please vote:
> +1 - I agree with the new structure
> 0 - don't care
> -1 - I disagree (explain why).
>

Re: [VOTE] Improve Ignite GIT Process

[Gianfranco Murador <mu...@gmail.com>]

+1

2015-06-07 16:02 GMT+02:00 Atri Sharma <at...@gmail.com>:

> +1
> On 7 Jun 2015 19:21, "Dmitriy Setrakyan" <ds...@apache.org> wrote:
>
> > Let's have a vote on the GIT structure proposed by the community (mainly
> > Brane and Cos).
> >
> > - Master should become the development branch for the next release.
> > - All individual ticket branches should be created off of the master
> > branch.
> > - When we are working on the 2 releases in parallel, we should create a
> > special release branch and merge it back to master, once the master
> branch
> > has been released.
> > - Master gets tagged for every release.
> > - Same CI rules as we have now apply - all CI tests must pass before the
> > merge of ticket branches to the master branch.
> >
> > Please vote:
> > +1 - I agree with the new structure
> > 0 - don't care
> > -1 - I disagree (explain why).
> >
>

Re: [VOTE] Improve Ignite GIT Process

[Atri Sharma <at...@gmail.com>]

+1
On 7 Jun 2015 19:21, "Dmitriy Setrakyan" <ds...@apache.org> wrote:

> Let's have a vote on the GIT structure proposed by the community (mainly
> Brane and Cos).
>
> - Master should become the development branch for the next release.
> - All individual ticket branches should be created off of the master
> branch.
> - When we are working on the 2 releases in parallel, we should create a
> special release branch and merge it back to master, once the master branch
> has been released.
> - Master gets tagged for every release.
> - Same CI rules as we have now apply - all CI tests must pass before the
> merge of ticket branches to the master branch.
>
> Please vote:
> +1 - I agree with the new structure
> 0 - don't care
> -1 - I disagree (explain why).
>