[LONG] About voting rules (Was: [VOTE RESULT] Merge IMAP code to trunk)

[Stefano Bagnara <ap...@bago.org>]

Noel J. Bergman wrote:
> Stefano Bagnara wrote:
> 
>> Noel J. Bergman wrote:
>>>> Ok, 3 days passed.
> 
>>> Code changes can be vetoed at any time, resulting only in the inability
> to
>>> cut a release containing them.
> 
>> it seems that we followed the right procedure.
> 
> You followed a procedure.  The point is that code votes are never closed.

This should be added to that page: it is a really important thing. It 
should be much more clear what does it mean "Votes should generally be 
permitted to run for at least 72 hours to provide an opportunity for all 
concerned persons to participate regardless of their geographic 
locations." and that this does not apply to code modifications.

In fact it should be cleared also why a VOTE is needed and when the VOTE 
start to have some meaning in a code change proposal. How much you have 
to wait to decide that you can go ahead and apply the change?
I think that the 72 hours and 3 +1 is a clear rule. Of course PMC 
members should make of their best to be able to reply in that 72 hours 
or at least to say they need some more time or anything similar 
otherwise the procedure has no more a clear workflow and this is BAD.

I also agree that a PMC member should have always enough power to raise 
a problem and say that something applied 2 years ago shouldn't be there 
and should be removed. But this has nothing to do with "the rule".

If you think that James project needs more than 72 hours we can increase 
it, but imho it is important to have a fixed amount of time otherwise 
people won't ever know if they are following the correct workflow or not.

>> http://www.apache.org/foundation/voting.html does not say anything
>> about your sentence.
> 
>> you should add the rule to that page so anyone will know how VOTEs work.
> 
> See the final paragraph of that page.  People get a bit "rule happy", and
> that's never good.

I agree. But if you say there is a rule, that rule should be written 
there, otherwise we can't consider we agree on that rule.

>>> Votes should generally be permitted to run for at least 72 hours to
>>> provide an opportunity for all concerned persons to participate
>>> regardless of their geographic locations.
> 
> Well, I was going to observe that 72 hours is a bit short when voting during
> a conference, over a holiday, etc., but had decided against conflating two
> points.

This is why I think that voting +/- 0 is always better than non-voting: 
because you let know people you are there.
I would accept to wait until ALL the votes have been casted if we only 
had a more reactive/active team ;-)

I don't know when conferences or holidays take place, so maybe it would 
be better if PMC members announce their unavailability when it happens 
so that votes will be made much longer.

If you instead think that we should use 120 hours instead of 72 for 
james, or 3 full days excluding saturday and sunday or any other similar 
rule feel free to propose it.

I just want to have a clear workflow, because I don't like to have 
doubts about doing something wrong simply because the rule is not clear 
or we have different opinions on what is right and what is wrong ;-)

> And you do need closure for some sorts of votes, e.g., a Committer, a
> Release, etc.  For code, you can operate on lazy consensus until a veto.
> 
> 	--- Noel


Ok, but this is not what I understand from "Votes on Code Modification":
I know my english is not good, but I'm almost sure this is not clear and 
people can't understand this from that page.

My understanding of the voting about code modification is that you can 
use 2 styles:

1) Lazy Consensus: this is an alternative to voting, and you simply 
start a message (without the VOTE prefix) to let people know you're 
making some sort of modification: "The patch below fixes bug #8271847; 
if no-one objects within three days, I'll assume lazy consensus and 
commit it." After the 3 days you commit it. Anyone can raise his own 
voice to block this or to revert this later.

2) Real Vote: three +1 votes are required for a code-modification 
proposal to pass and no -1 votes. There is no other rules.

I think that major changes should always follow the real vote workflow, 
while lazy consensus should be used for minor things.

If this is not what the ASF intended with the rules, I believe it should 
be made more clear because I think I'm not the only one interpreting 
that words this way.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org