On Mon, 6 Mar 2006, Stephen Colebourne wrote:
Henri Yandell wrote:
I'm not tied to any of the things I'm suggesting - except the strong
belief that Jakarta as a community of communities cannot work. So I'm
definitely in favour of more shared site and less individual site - I'm
in favour of a flat Jakarta, both in terms of SVN acces and not allowing
subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta
Velocity DVSL); I'm in favour of sharing the decisions - rather than
having a slice of the PMC informing the main PMC of their decision.
It just seem to me to be impossible to imagine a commons-betwixt developer
caring about velocity-tools, or a taglibs-foo developer caring about bcel.
There is no community in common.
In commons we care about a broad range of different projects. But the degree
to which we care about components other than our own has reduced over time
(roughly inverse proportional to the number of components).
So yes, in the past I was gung-ho about commons taking over the whole of
Jakarta. Now I recognise commons can barely manage itself, let alone any more
projects. Size matters.
(In fact, commons often behaves as multiple communities already. Its natural
and organic. I'm embracing it by proposing Jakarta Language Components.)
At some point a recognition needs to occur that hierarchy is not evil. We are
all developers. We group things into hierarchies naturally. If you flattened
all the turbine components on the home page of jakarta all you'd be doing is
forcing the reader to group them. The turbine components will always 'belong
to' Turbine.
In summary, I believe we are many communities, not one. What unites us is our
size, in that each individual community is too small to stand alone as a TLP.
There is the *potential* to build a cross-Jakarta community in *addition* to
our smaller communities, but it requires care and nurturing. Perhaps a single
jakarta-user ML, or a forum are the places to start.
Generally, I'm not in disagreement with the above. The Turbine point is
wrong - JCS, Maven and others came out of Turbine - the Velocity
components will always be Velocity based, but Turbine components seem to
do well at being distinct entities.
Grouping hierarchies is good. It'll be a shame to enforce mutual
exclusiveness, but it'll be hard to have groupings as a tagging if we
divide mailing lists along those lines. Multiple mailing lists is quite
simply necessary due to the weakness of our communication tools.
Commons taking over Jakarta is about the Commons ideas becoming the
Jakarta ideas. "Java Component" would be put into the charter. SVN would
be open, not closed. Unified mailing lists would be aimed for as much as
possible.
And yes, I agree that you can't ignore the fact that Jakarta is a set of
multiple communities. The important word is disjoint - Jakarta is a
disjoint set of communities, we don't have enough overlap. Commons is a
(erm...opposite of disjoint) set of communities. Your Language Components
suggestion will not split the community, there will still be a high level
of overlap.
Commons shows that we will always have multiple communities - but that we
need to keep the overlapping high. The biggest dangers to overlap are:
* Subprojects of subprojects. Thus my attempt to get us to classify
Jakarta as a large collection of components - even if we group them for
communicative needs. So in SVN we would not reflect the groupings - either
in terms of url or authentication. Officially we would not group them,
they are all components of Jakarta. Basically anything we can come up with
to not create islands that won't be damaging.
* Autonomic mailing lists. Lists on which all discussions concerning the
project occur. TLP discussions, discussions like these, legal issues, even
votes should be taking place in front of the whole community and not the
tiny subset. I know there will be cross-thread issues, and people may be
unhappy with the noise of a single list (but given the general noise level
of these issues I don't think it would be that noisy a list) - but it is
critical to keep even a community of communities running.
Both Stephen and Martin have mentioned HTTP Components. Let's not forget
that Commons HTTPClient was an utter failure. We moved it to its own dev
list due to its own noise, and it became its own community with zero
overlap. If all we do is rearrange Jakarta into new islands, we'll have
failed again.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
