avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: Charter.txt
Date Wed, 04 Dec 2002 14:38:31 GMT
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> >Steve, your fears are duly noted.  Keep in mind that it is 
> the PMC that
> >must be unanimous--not the general committer populus.
> >  
> >
> THAT IS WHAT I AM TOTALLY OPPOSED TO.
> If the PMC cannot reach agreement on something because it put 
> in place 
> policies that effectively can lead to blocking its own 
> ability to take 
> action - you have destoyed the PMC.

Let's look at the pieces one at a time, and decide as a community.


> >I am sure that people who have a proven track record of being able to
> >work with others can come to agreement.  I am also sure that 
> unanimous
> >has to work any time there is a legal issue at stake.  Remember PMC
> >does not make technical decisions so there is unlikely to be an undue
> >amount of blocking--and never for frivolent reasons.
> 
> The MUST BE zero possibility for blocking.  Without that - 
> how will the 
> PMC every reach closure on a dispute where you dono't have concensus 
> because one party who happends to be a PMC member can block 
> the decision 
> process?


If you are refering to a removal process, then they are excluded
from the vote--it is a clear conflict of interest.

Honestly, the types of changes where unanimous decisions are required
impact the legal status of this community.  The only time that we
will have a problem is if one party throws together a proposal, puts
it up for vote, and tries to hammer it through.  I *refuse* to be
subject to that kind of bumrushing tactic and expect to be held
legally bound to it.

If the PMC works together to come up with a proposal by a concerted
effort, and all parties are aware of what is in the proposal, then
the voting process is merely a formality.  The bottom line is that
the process *does* work in other communities.  The only reason why
it wouldn't work in this community is if the PMC members are too
self-serving.

> >PMC is responsible to oversee the legal aspects of this community.
> 
> Exactly!
> That is why it cannot be hamstrung with *nice* policies for 
> how we think 
> the would *should* be.  It *must* be structured so that it 
> can *always* 
> deal with *real* world.


Funny, it is from an existing and functioning TLP that lives in the
real world.  They behave like professionals, and look to the overall
good of the XML community--not their respective corporation's good.

It *can* function for us, and it *should* function for us.  Those
measures are there to slow down changes that can have a dramatic
impact on our community.  We all have to be on the same page.

If I legally have to sign something, I have to be willing to do it.
How can we be the disenting voice and be "forced" to sign something
we disagree with?  The types of changes that should require
unanimous PMC vote are:

* Creating and ratifying legal documents, like the charter and
  resolution.

* Removing *disruptive/destructive* committers from Avalon in the
  unlikely event that we would experience one of them.  Another
  variation would be removing someone from the PMC--but not from
  committer status.  In the latter case, the guilty PMC member
  would be excluded from the vote due to conflict of interest.

Elections of PMC members are done by nomination and vote.  Selection
of the chair should be done by 2/3 majority of the PMC.  A chair's
term should be 3 months, where it is up for re-election at that
time--unless the chair resigns before that time, in which case an
emergency election will take place.

In reality there are only two things that I firmly believe we should
have unanimous PMC consensus, and the rest I am inclined to agree
with you.

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message