incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: veto stuff
Date Thu, 07 Nov 2002 18:18:31 GMT

Nicola Ken Barozzi wrote:
> > 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.

no.  there is no 'equally compelling reason' that can override
a veto.  it's not about opinion, but fact.

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

if the veto/+1x3 policy applies, it is absolutely
bitwise.  if it doesn't apply, use a different policy.

> 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)

as stated, this is completely unambiguous: the original committer
is in the wrong.  if the justification for the veto was on other
than technical grounds, it may have been invalid; if the justification
was technical (and not *demonstrated* to be incorrect), the
veto was valid.  not only should the original committer have
honoured it, but the community should have enforced it.

all hypothetical and highly situational w/o knowing any actual
facts of any such incident.

> 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.

the rules exist.  either a veto is valid and the item being
vetoed must submit, or it is *not* valid and the vetoer
is the one who must submit.  it is up to the community to
enforce these rules, either through peer pressure or possibly
the extreme step of suspension of privileges.

according to the structure of the foundation, it would be
reasonable to bring cases like this to the pmc for a decision.
if none is forthcoming, the chair of the pmc, who is the
officer of the foundation in charge of the project, may make
a determination.  failing that, the issue could be brought
to the board, which is the final authority.  even that is
not completely final, since members can elect different directors
and re-raise the issue.  such an occurrence would be a severe
pathology, however.

> > no.  a veto may not be overridden.  that is fundamental.
> What about rules for revolutionaries?

what about them?  that was a proposal written by one person and
partially adopted by one project.  it is not asf policy, though
it is an implementation of the basic how-to-deal-with-a-veto
rules.  an implementation which provides support from the
project structure.  valuable experience has been gained from
its application, even if not everyone agrees on the conclusions.

> It's quite easy to block (r)evolution by vetoes

technically valid vetos?

> > 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?

ultimately, the foundation officer in charge of the project.
who, as i said, will probably work frantically to keep it
from landing in its lap, and will try to come to some pathway
that is best for and most acceptable to the community.

what follows is my opinion, based on intimate experience.  i
believe it to be an accurate portrayal of reality.  i could be
mistaken, and i hope roy and others will correct me if so.

> But it still smells like benevolent dictatorship...

in a way it is.  be very clear on this.  it is not a demoncracy.
there is a very definite structure of authority and responsibility.
the code belongs to the foundation.  the foundation is the
members.  the members elect the board to oversee the foundation
and ensure its continued existence and health.  the board appoints
officers to oversee and be responsible for projects.  these officers
are ex officio chairs of the projects' management committees.
beyond that point, the structure becomes more diverse on a
project-by-project basis, since how each pmc will 'manage' its
project is something it and the chair will develop that, in
their opinions, is best for the project and the community.

it is a balancing effort.  the only rights here are those invested
in the members, who comprise the foundation.  the board serves
at the pleasure of the members; the pmcs serve at the pleasure
of the board.  that is the top-down authoritarian legal view.
balanced against that is that the only way the foundation will
continue and succeed is by having healthy communities; healthy
communities mean committers who are [mostly] content.  which
means that the board and the pmcs can only fulfill their functions
by supporting the committers.  the factors of 'contentment' include
(but are not necessarily limited to) 'let me work on the code without
joggling my elbow,' 'provide me the tools and infrastructure i need
to work on the code,' and 'provide me an environment of peers in
which i can have fun.'  therefore, the foundation guidelines -- and
each projects' -- are (or should be) geared to satisfy these needs
in the most constructive (or least destructive) way that can be

which raises another interesting point.  i think no-one will
dispute that there are people who are better qualified than
others to do <random technical magic>.  however, when it comes
to figuring out how to make lots of people 'play nice' and
constructively together, it seems everyone considers itself
an expert.

well, not everyone.  some people, myself included, recognise
that as a talent or acquired skill, and, deep down, realise that
there are people better qualified in that area than ourselves --
even if we have difficulty admitting it publicly or even to

i think what has been missing here is not the structure, but
*awareness* of it and its significance.

okey, i've sounded off on my opinion enough, i think.  i'll
go don my asbestos environment suit now.

View raw message