xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arved Sandstrom <Arved...@chebucto.ns.ca>
Subject Re: VOTE: PMC size
Date Tue, 06 Mar 2001 10:56:55 GMT
At 12:28 AM 3/6/01 -0500, Scott_Boag@lotus.com wrote:
>
>"Roy T. Fielding" <fielding@ebuilt.com> wrote:
>> That is, the PMC is supposed to be
>> elected by the committers on the project, or include all of the
>committers
>> on the project, because that's pretty much the only way to ensure that
>> what we do remains a true collaboration and doesn't degrade into some
>sort
>> of consortium or a mirror of our real jobs.
>
>Given Roy's note, I should add to my list:
>
>E) include all of the committers on the project
>
>I would vote, in order of preference:
>
>E -- I like this because it is inclusive of the people who do active work.
>If you put code into Apache on a regular basis, you should have the right
>to be part of the decision making process, even if they are "dry" issues.
>
>D -- I like this because it is potentially a more manageable version of E,
>but I still like E better.
>
>A -- If we can't have representative input, then the PMC should be very
>small, and it's scope severely limited, as much as possible under the ASF's
>bylaws.  Strictly "to make sure we do things legally and without recklessly
>endangering the foundation's assets (the good name and all of the code
>contributed to the foundation)", and where privacy is required.  For
>instance, in this case the decision to include a new project should not be
>part of it's scope, this should be put to a committer vote, with maybe a
>anonymous vote from the PMC able to veto.
>
>-scott

It would probably be useful for the brothers and sisters (all 
committers...heck, anyone reading this list) to be aware that Roy's mail is 
the logical culmination of arguments and debate on members@apache.org. In 
effect, we could reach no useful conclusion. But that dissolution and 
reformation was going to happen is not news (to us).

The immediate problem as I see it is that Roy presented the role of the PMC 
in the light of "PMC as legal entity". The entire reason we were arguing 
over PMCs and alternative bodies etc etc ad nauseam on 'members' is 
_because_ several (many?) of us felt that in between the level of members 
(who have a legal function but are otherwise tasked to do little), and 
committers (who are doing the work), there seemed to be an intermediate 
level that could do more.

Roy is presenting the view of PMC as it _must_ be, minimum. Which is his 
responsibility. Unfortunately, this takes us right back to square one: 
legalistic PMC, and we _still_ want (I assume) one or more higher-level 
groups to have more functional responsibilities within XML Apache.

I would propose that we simplify matters initially by not looking for a "new 
model" PMC. We just conduct an all-committer vote that picks out maybe 4-6 
committers to sit as the "dry" version of a PMC - Scott's description of 
option A.

I also propose 2 standing working groups. The first is composed 
automatically of all committers, and this is where decisions like forming a 
new project are made. This first group also forms and dissolves all the 
other working groups. The second standing working group is an advisory 
group, possibly 5-10 people, and is composed of people that committers have 
voted on (selected) from among the number of external individuals who 
nominated themselves these past few weeks. I saw a whole bunch of 
enthusiastic individuals who obviously have very useful things to offer. I 
would like to not lose that input.

All other functions are accommodated through the already discussed mechanism 
of having temporary working groups. The all-committer body (standing WG) has 
identification and management of these WGs as one of its primary functions. 
Scott's Architectural Mgmt Council could definitely be one of these. These 
WGs would be composed of committers _and_ members of the advisory group, as 
appropriate.

Just some thoughts.

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


Mime
View raw message