On Tue, Dec 21, 2004 at 08:48:59PM +0800, Niclas Hedhman wrote:
>...
> Now, section 6.3 in the ByLaws of the ASF doesn't rhyme entirely correctly 
> with the quotes from the IRC session.
> 
> You said; The PMC is an artificial construct.
> Section 6.3 forgets to mention that.
In essence, the PMC is constructed by the Chair. The Chair defines how
the PMC is gathered and its rules and policies. There is nothing in
the ASF Bylaws that specify any of that stuff. Just that there will be
a committee.

The further connotation is that "it isn't real". To some extent, it
really isn't since the Chair is free to change it as necessary.

So. Take to the extreme, a PMC is ephemeral. But as I pointed out
before, the Board has expectations of how a PMC is organized and run.
If the Chair gets too wonky, or plays too loose with it, then there
would be repercussions. My statement was merely an extrapolation to
the extreme. Not a statement of the typical.

> You said; Aaron IS the PMC.
> Section 6.3 uses the wording "shall be primarily responsible for project(s) 
> managed by such committee"

As I said in my other note, that phrase was from the point of view of
the Board. The Board doesn't deal with the PMC as a whole. When we
want to talk to the PMC, we talk to the Chair.

> IANAL, and is not comfortable in trying to make the Section 6.3 clearer, but 
> I 
> beg those who a. understand the mechanics properly, b. capable of formulating 
> the language, c. has the authority to do so, to re-phrase into a more 
> accurate depictment of the PMC, its Chair vs its members.
> 
> I mean, if the PMC is purely advisory, then write that.

As mentioned above, when taken to the extreme, yes: it can be viewed
as advisory. But that is not the *typical* situation. The typical is a
consensus-run committee and the Chair is simply a normal voter. In
healthy PMCs, you hardly ever notice that one of the people happens to
have a funky "VP" behind his name. It really only surfaces when the
Chair asks for assistance with putting together the quarterly reports
to the Board.

> This whole episode is also marred by "Project ByLaw", which I have been told 
> does not to exist (or do they? confusion!), yet is mentioned that the PMC is 
> tasked to establish them.

Yah. It's a poor choice of wording since it leads to confusion with
the ASF Bylaws. And it also connotes that they are the ultimate law,
when (as Ken notes), they cannot actually countermand the directives
of the Board or the restrictions of the ASF Bylaws.

We have discussed on a number of occasions that we'd like to create a
single set of "PMC Bylaws" which would apply to *all* PMCs, and then
strike that text from the boilerplate TLP creation. Instead, we'd just
have some docco on "here is how an ASF PMC normally operates".

> And those established at Avalon seems partly being 
> contradictory to what Greg says (which I take as most authorative at this 
> juncture).

I'm unclear on this part, so I'm not sure how to explain. By
contradictory, do you mean their existence should not have happened?
Assuming that was your point... no, they're fine. Many PMCs have
explicit "Bylaws" which describe how the PMC operates. But there are a
few issues with that:

1) as mentioned above, they are not the ultimate law
2) the term Bylaws can be confusing
3) in a properly functioning PMC, they are irrelevant (*)

So their presence can be helpful to describe to newcomers how things
work, but they need to be viewed in the proper context (and that
description is typically lacking).

(*) When I say irrelevant, let me describe a case in point:

   The HTTPD PMC never consults any "Bylaws". We don't really have
   them. We simply use the standard ASF voting rules used on any dev
   list. We know how to build consensus and we operate that way. There
   are *very* few cases where we call a vote to *force* a direction.
   Votes are used to examine whether consensus is present, rather than
   to make a decision. We had a long discussion on the PMC a few weeks
   ago where we stopped and called a vote. But that was mostly to try
   and figure out what the various opinions were -- to clarify things.
   The vote results didn't actually "stick". In the end, the group
   came up with a rough consensus and turned that over to Sander (the
   Chair) to take action with.

   Now, let me contrast that with behavior that I observed in the
   Avalon PMC. On many occasions, there were fractures in the
   consensus, so a vote was used to *force* a decision. "But we voted
   on it" was the refrain. Yah, great. The result wasn't a consensus,
   merely a vote result. With a true consensus, some few will agree to
   abide with the majority opinion. They know they're the odd person
   out, but respect the others and agree to back off. This didn't
   happen often in Avalon; the minority felt pushed around and
   disenfranchised and alienated. Eventually, they just left. The use
   of votes was a mechanism for forcing a direction. All that was
   needed was one more vote than the "other position", and people felt
   they had a mandate. Bleh. They just had a majority vote.

> Avalon bylaws are now no longer online, but let's look at an example of 
> contradiction in the Excalibur TLP bylaws, passed by their PMC [1];
> 
> http://wiki.apache.org/excalibur/Bylaws
> 
> Under 1.2.2.4 Project Management Committee, first paragraph, second sentence;
> <quote>
> The PMC is responsible to the board and the ASF for the management and 
> oversight of the Apache Excalibur codebase.
> </quote>
> 
> Well, apparently the PMC is not responsible and not authorative, only the PMC 
> Chair.

In the strictest sense, yes. But in the everyday sense? No.

IOW, for all intents and purposes, it *is* the PMC. But when push
comes to shove and the PMC is fucking up, then the Chair has to do
whatever is necessary to act in the best interests of the ASF.

> IMHO, these types of discrepancies are the true root of this thread. And 
> instead of dismissing everything from my mouth at sight and being sick of me 
> dragging this on, please take a moment and review my findings and move for a 
> clarification of the PMC role (and the Chair), its responsibility and 
> authority, and make that in writing to avoid any future misunderstandings 
> elsewhere. And in the same go, ask the PMCs to review their "PMC Bylaws" (if 
> they exist) whether they are in conflict with this clarified view.

As I mentioned, in the typical case, they are totally fine. Avalon ran
into a set of extreme situations, and my points [in IRC and other
places] were made to demonstrate where the buck *really* stopped. And
with that, to let Aaron know that he had the right and responsibility
to do what is necessary rather than continue to get hamstrung by a
defective PMC membership. When you look at the wording in the Bylaws,
there is nothing that prevents a Chair from saying "my PMC will have
no members. I will be the sole decision maker." That Chair better have
good reasons for that, but it *is* possible.

On one occasion during the summer, the Board told one of the VPs
something along the lines of, "stop asking us to make your decisions.
we put *you* in charge to do this. so go do it." The VPs are officers
of the corporation, in every sense of the word in US corporate law.
When things go to shit, they have incredible leeway (and the
responsibility!) to make things right. But please don't confuse the
typical from the atypical. If a VP was running rampant without due
cause, then they wouldn't be a VP for long :-)

FWIW, I liked your phrase in another email about renaming the "PMC
Bylaws" to something like "Standard Operating Rules" or somesuch. Tho
my personal opinion is to just lose them and have one set of rules for
all ASF PMCs. We haven't done that in the past because the idea has
always been to let the PMCs figure out what is best for their
community, rather than to the Board (i.e. the ASF) mandate a
particular set of rules.

I hope that clarifies things.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to