On 3/5/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> Henri Yandell wrote:
> > -1.
> > My reason for being against the idea is that it's a continuation of
> > Jakarta as a set of communities without much overlap.
>
> This proposal, as most others do simply represents reality - that
> Jakarta does contain sub-communities. Maybe the Apache board has trouble
> with that, but in the end most of us don't.

The current design of the Apache foundation has trouble with it.

In terms of options - my current one is to campaign strongly for
Jakarta to do as much as possible to be a single community. If our
consensus is strongly that we want Jakarta to be nothing more than an
umbrella of communities, then I'll have to change tack and suggest
various ideas that will piss the foundation off :)

Namely - PPMCs, individual subproject chairs, subcharters - in effect
a copy of the Incubator and the ASF. The fact that Jakarta is nowadays
about small components would be my reasoning behind this - it can't be
a normal TLP and its subprojects very strongly do not want to be TLPs
of their own (in some cases they couldn't be, in others they don't
want to leave). The outcome would be either that we could go ahead
with an Incubator style structure, or that we'd have to terminate
Jakarta and subprojects would have a choice of TLP or die (that's the
only time I think the stick would be anywhere in all of this long term
planning).

The one thing I won't do is have the ASF having one definition of a
project, and Jakarta having another. I really, really hate it when
people look the other way and ignore that what they're saying doesn't
represent reality (they being the ASF in this case).

> I would suggest that the concern shouldn't be with the presence or
> number of sub-communities, but instead the aim should be to offer
> something positive at the Jakarta level that pulls everyone within
> together. The carrot works better than the stick in OSS.

I'm all ears if you have thoughts in that direction :)

> (Maybe Jakarta-level could have a single user ML for all Jakarta. Or
> even better focus on a Jakarta-wide forum system.)

The shared community needs to be at the oversight level; this just
causes pain for the users. I'd be +1 on a user list per component if
that's what was wanted or a single user list - it's not that important
to the community issue.

> > I'm +1 to the idea of splitting Commons up into groupings - provided
> > we don't break up the community.
>
> This doesn't read right. A community comes together around the ML. And
> thats a good thing, not a bad thing. This proposal tries to take one
> large extended family and break it into two smaller more manageable units.
>
> Perhaps you are thinking of a website only grouping? Well that adresses
> no real issues I can see. Its a shallow view on the problem. It leaves
> the underlying issues. One ML for all Jakarta won't work - its artificial.
>
> And how is Jakarta Http Components, or Jakarta Web Components OK, but
> not jakarta Language Components?

They're not. Change my -1 to a -0; JLC is as good a grouping as JHC
and JWC: but the grouping concept as you've described it is not enough
to make any of them successes.

Hen

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

Reply via email to