incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: veto stuff
Date Sat, 09 Nov 2002 11:52:18 GMT
Rodent of Unusual Size wrote:
> [long]
> 
> 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.

I used wrong words.
I meant to say that "the other side has equally compelling arguments 
that seem to demonstrate that the justification is not valid.

- A commits.
- B vetos and says why, and the justification is rational.
- A says that the justification of B doesn't stand, and it's rational too.
- The community is split between the two opinions.

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

I think that many decisions are not bitwise and are more about the 
direction of the project.

I think that these issues must be dealt with without vetos but with 
majority vote. The veto of course will stand for the commit in question 
but the issue must then be raised for a more high-level vision resolution.

Which basically means: ok.

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

Not everything is demonstratable.
Some commit can introduce problems, while solving others.

The main point is that the vetoer IMHO is at least morally obliged to 
find a solution for the issue the commit was trying to solve.

I agree 100% with all the rest and find it the most comprehensive and 
terse description of the process.

Thank you :-)

> 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
> devised.
> 
> <digression>
> 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
> ourselves.
> </digression>
> 
> 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.


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message