Re: Requesting clarification in ByLaw text.

2004-12-22 Thread Greg Stein
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 
 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 

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 

Re: Requesting clarification in ByLaw text.

2004-12-22 Thread Niclas Hedhman
On Wednesday 22 December 2004 15:27, Greg Stein wrote:
 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.

That would make *me* really happy and worthwhile, because until a few days 
ago, I was under the impression that there were bearing to the PMC Bylaws.

I give you the ones I can find;

  /   /
 / / 

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

Re: Requesting clarification in ByLaw text.

2004-12-21 Thread Niclas Hedhman
On Tuesday 21 December 2004 20:48, Niclas Hedhman wrote:
 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

Sorry, I missed a few words here. Should be;
... yet is mentioned in the Board Resolution forming Avalon, that the PMC 
  /   /
 / / 

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