incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: release voting
Date Wed, 20 Dec 2006 10:04:37 GMT
On Dec 19, 2006, at 8:02 PM, Greg Stein wrote:

> On 12/11/06, Roy T. Fielding <> wrote:
>> ...
>> > Can a PMC chair veto a release?
>> No.  A chair only counts as one vote.  A chair's only special powers
>> are to receive things officially and ensure that the PMC does vote.
> Euh... no. Nowhere is that stated in the ASF Bylaws. They're quite mum
> on what the Chair can do.

Yes, but Bylaws are subject to the General Corporation Law of the
State of Delaware

and committees, unless explicitly stated otherwise, are expected to
govern themselves under generally accepted codes of procedure.  Like,
for example, "The Standard Code of Parliamentary Procedure, 4th ed."
or some variation on Robert's Rules.  Both of them disagree with
your interpretation.

Officers can be delegated certain duties by the board, and once
delegated the officer has the implied power to do whatever is
necessary to carry out the functions and duties of that office.
But those duties must be specifically delegated in the resolution
or bylaws that create the office.

> The Chair *is* an officer of the corporation, though, and that implies
> a lot more than what you've stated. An officer can make binding
> decisions for the corporation. In the case of a project VP (the
> Chair), they can effectively do anything necessary within the realm of
> their project that is appropriate for that project. Consider:
>       RESOLVED, that the office of Vice President, Apache Labs be and
>       hereby is created, the person holding such office to serve at
>       the direction of the Board of Directors as the chair of the
>       Labs PMC, and to have primary responsibility for management of
>       the projects within the scope of responsibility of the Apache
>       Labs PMC; and be it further

The VP is delegated the duty of chair of a committee and primary
responsibility for management of the projects.  *Everyone* knows that
the chair of a committee does not make decisions *for* the committee.
The resolution does not say that the VP makes project decisions or is
delegated authority over the project as a whole.  The only reason for
the four paragraphs above it is to state that the board is delegating
that authority to a committee, not to a single person.

        NOW, THEREFORE, BE IT RESOLVED, that a Project Management
        Committee (PMC), to be known as Apache Labs, be
        and hereby is established pursuant to Bylaws of the Foundation;
        and be it further

That is the operative authority and it is not vested in the chair.
This specific type of delegation is defined by our Bylaws and is
specifically intended to be in the form of a committee, which
means that the decisions are made by committee decision.

The chair is not delegated authority over the projects -- only
responsibility to manage the committee, and thus the only decisions
that a chair can go hog-wild on are the establishment of unusual
project bylaws or appointment and removal of committee members
(which requires an ACK by a board member).  The only way that the
VP can make unilateral decisions for the project is by first
removing the rest of the PMC -- otherwise, it is the committee
that is given authority to make project decisions, not the VP.

Putting it another way: there would be no reason to establish a
committee if decisions are to be made by the officer alone.  Any
officer is capable of creating their own committees to delegate
their own duties (though not their responsibilities), so the board
resolution to do what you indicate would just appoint an officer
with both responsibility and authority and be done.  The whole
reason for appointing a committee, and further to retain control
over the membership of the committee, is to have a committee duly
consider and act on project decisions rather than an individual.

> All of our TLP resolutions have that paragraph. With that paragraph,
> and VP status, I consider the Chairs to be able to do just about
> anything that is in the best interests of their project (and not
> counter to other interests of the ASF).

*shrug*  I don't think that consideration is supported by either.
We'd probably have to get Drew Wright to judge what it means,
since he wrote the original paragraphs.

> The ASF Bylaws basically restate the above:
>   "...the chairman of each Project Management Committee shall be
>    primarily responsible for project(s) managed by such committee,
>    and he or she shall establish rules and procedures for the day
>    to day management of project(s) for which the committee is
>    responsible."
> I've always interpreted the VP as the one to define the rules of the
> PMC. They are the actual "hand of power", but the Board expects them
> to operate that power in a certain way. If they misuse it... well,
> that's the end of that. Those expectations are things like voting
> procedures, consensus rules, blah blah blah. There is a cultural
> definition of *how* the VP should act, but when push comes to shove,
> I've told Chairs on a number of occasions, "dood. you're an officer of
> the corporation. *you* make it work. you have extremely wide leeway
> when it comes to handling your problems."

Those are all matters of project bylaws (how the committee operates),
not project decisions.  Yes, the VP does have the power to act when
it comes to managing the committee.

This thread was not about managing the committee -- it was about
a release decision.  A purely technical decision over which authority
has been specifically assigned to a committee.  No chair has the right
to override decisions of the committee.

> When Ken dumped the entire Geronimo PMC, he did that under his rights
> as a VP of that project. He felt that was the appropriate action at
> the time. I believe he had every right/ability to do that, and the
> Board backed his right to do so. Now... if we saw Chairs doing that
> every other week, there'd be hell to pay. Again, there is an
> expectation of behavior, but there is actually very few written
> rules/restrictions.
> In this case, if we saw a Chair taking unilateral actions within a
> project, we'd call him to the carpet and demand an explanation. If he
> had a good one, then alright. That's how it works.

No, that's not how it works.  If a chair makes a unilateral decision
for a project on a technical issue, then our project guidelines are
a bunch of rubbish.  We have PMCs for a reason.  It isn't pretty and
isn't the most efficient form of governance, but it balances the
powers sufficiently to keep our officers (and our board) from
getting too high off the fumes of power and wreaking havoc on the
long-term viability of our projects.

Checks, balances, and the principle of least authority are all
part of good governance.  Probably the only way I could kill the
httpd project would be to start making decisions for it, even if
they all seem like good decisions at the time.  Heck, even if
they all happen to be the best decisions possible, it would still
kill the project if others stopped thinking critically about the
products and simply waited for me to decide: death by atrophy.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message