incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: veto stuff
Date Thu, 07 Nov 2002 13:58:52 GMT

Rodent of Unusual Size wrote:
> i'll consider this more fully later, but for now:

A comment on why I wrote this: I really agree with the principle, and in 
sane communities it works *very* well. With these random thoughts I'm 
just trying to see if we can rationalise a way of getting out of the 
problems that arise on less healthy projects.

> Nicola Ken Barozzi wrote:
>>0) any vetoed commit must be reverted immediately till the issue is not
>>1) a veto can be formally challenged not before two weeks(?) after it is
>>cast; this prevents from challenging as a norm.
>>2) when a veto is challenged, someone must back who did the veto with
>>his own explanation of why it stands technically (not necessarily why he
>>agrees); if not (time?) then it's null.
> no, because that makes it a requirement that there essentially be *two* -1 votes.

Well, no. It happenes that someone vetoes something with a rational 
explanation, but the other side has equally compelling reason to have 
the commit pass.

Not everything is bitwise, especially in framework projects where it's 
all very conceptual.

It has also happened that a justification for a veto was deemed null by 
the original committer because he effectively didn't concede it was 
correct, while the other says it is, and the community splits between 
the opinions. (hence the following point 3)

This really disturbs me, the fact that when these things arise there are 
no rules I am aware of that are used in not keeping the community at the 
mercy of these guys.

Usually it boils down to the question: who decides?

I suggested peer review here on the veto motives, instead of a 
benevolent dictator mechanism.

Not that I find it particularly elegant though.

>>3) else, if it still stands, a majority vote can be taken to decide if
>>it should stand.
> no.  a veto may not be overridden.  that is fundamental.

What about rules for revolutionaries?
It's quite easy to block (r)evolution by vetoes, and sometimes it just 
seems that the first one to commit will loose since it will get vetoed.

Forking is the way to go for revolutionaries?

I like the way Tomcat has dealt it, by an internal fork in CVS and 
majority vote to switch codebases.
It was not nice for the community, but the community was split anyhow, 
and it solved the deadlock.

> as another possible alternative, perhaps vetos can be appealed to the pmc.
> well, not appealed, but a petition made that they be reviewed.  as with
> the u.s. supreme court, if the pmc chooses not to consider it the veto
> stands.  ultimately, any final decision comes down to the pmc chair (who
> will probably work assiduously to keep things from going that far) because
> that person alone has the ultimate responsibility to the foundation for
> the project. (under the current bylaws.)

Ok, this is basically a possible solution, but actually, it has not been 
so clear in many projects, also because some PMCs are not very involved 
in all the (sub)projects and don't interact this way.

I suppose that with more pmcs and flat project structure this will get 
better and better.

> this is a very murky area, but until some final decision is made, we need
> to stick by the current rules -- which means vetos may not be overridden,
> but they may be worked around through the provision of alternatives that
> address their concerns.


> commit access is a privilege, not a right.  if someone uses vetos capriciously --
> or ignores them -- despite warnings, the suspension or revocation of commit
> privileges should definitely be considered as an option.

Again, *who* decides it?
*Who* can propose it?
*How* should it be voted?

IMO it's important we write this down clearly in the incubator docs.

Probably the best solution to this is not too many new rules but a clear 
definition of responsability on resolving these issues.
But it still smells like benevolent dictatorship...

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message