www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@covalent.net>
Subject Re: [discussion] Jakarta PMC bylaws change
Date Mon, 04 Nov 2002 18:26:59 GMT
I partially agree with Dirk's opinion. A very large PMC where people
don't feel a direct need to participate is wrong. 

That's the reason I think 'active participants who volunteer for PMC' 
is the right solution. If someone doesn't feel 'active' in jakarta or
doesn't have the time or wish to act as a PMC member - he should be
'emeritus' or shouldn't be an active pmc member.

If someone is active in jakarta he probably has all the reasons to
be active in the PMC as well - because most issues will affect him.
A license problem in a project that you use is a license problem for
your project too. And the motivation to solve this is pretty strong.

The process should be as objective as possible and bottom-up driven -
the number doesn't matter that much as long as everyone is motivated
and affected. 

If the people in PMC are only a subset - it is very likely the 
'hierarchy' issues will affect us. People might feel their 
membership in the PMC gives them extra power on day-to-day
project activities. Or we may have extra politics on the 


On Mon, 2002-11-04 at 09:51, Dirk-Willem van Gulik wrote:
> On Mon, 4 Nov 2002, Stefano Mazzocchi wrote:
> > Can you tell me what's wrong with a PMC which is almost silent, is
> > composed by committers and manages just one codebase? sounds like an
> > ideal situation for a PMC.
> >From that perspective nothing. Assuming that all is well... and the
> silence does not mask a certain sort of inertia.
> However bear in mind that HTTP is small, has very easy and almost
> 'objective' external requirements in the form of RFCs and had a relatively
> small code base. Even the rewrite of 1.3 to 2.0 to address some fairly
> well known issues is/was relatively simple compared to some of the major
> engineering and dust being through around elsewhere.
> Now if this would be all - no worries. However I personally think that the
> transition from that one HTTP crowd to one for HTTP, one for APR, etc, etc
> was already showing that something is a bit amiss in the scaling; even
> though the group of peopple is nearly overlapping; long term goal, feature
> creep in APR, versioning issues between APR/HTTP and even getting release
> notes out with some sort of coordination with php/perl treading-aint-work
> warnings, required a fair amount of noise in order to get the coordination
> they required.
> I cannot help to think that a much smaller group of people across those
> projects whould have done better than the current cabal keeping things on
> track simply by being a smaller focal point who know that they cannot
> dodge the issue.
> However it is not here where I see the major issues exposed right now -
> but when scaling up and over to:
> > > It is the jakarta/xml ones which worry me; as they are so much bigger and
> > > deal with some much more code; a lot of which does not have a nice RFC or
> > > clear set of requirements to easily compare options or provide guidance.
> >
> > Yes, many agree with you in this vision and I think Sam's proposal goes
> > in the direction of creating an evolutionary escape path or, at least, a
> > way to have spread the word about things for those who won't make it
> > here on community@.
> Right.
> > Moreover, I don't think a PMC with a hundred of members will behave any
> > worse than a PMC with just a few of them.
> And I do think it is; as a PMC of a hundred members will never act quicker
> or more focused/quick as a group of 5-10 people recruited out of those 100
> who have a task (say investigate a license issue) and know that there are
> a 100 people looking at them to get it done.
> Now having said that; perhaps we need to cycle those 5-10 people much more
> ofter; as I agree something is amiss. But I think making them a 100 is not
> the right track - and that is where I see the main flaw.
> And I also think that too large a cabal will simply create 'chair's whose
> job is much bigger than a volunteer can handle. It is that task I'd like
> to split among 5-10 people. As ultimately the board will continue to chase
> chairs to get things done. And it is easier for a chair to prod a few
> people nearby than to galvanize the populus as a whole for the sort
> of boring tasks asked.
> > I really don't think that it can be worse than we have today, so +1 from me.
> Aye - as I said - short term it is our best option - I think; and if I
> where a jakarta-head I'd certainly give it a +0 or +0.5.
> Dw
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org

View raw message