commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin van den Bemt <>
Subject Re: [all] Together, and bricks apart
Date Sat, 03 Dec 2005 14:56:26 GMT
Hi all,

Like your list Henri. Here is my list (with some overlap..)

My ideas to improve things are :

- Move sandbox components to the background (at least on the commons page). If the components
are worthy, they will pick up interest without it. For now it looks like just another list
of components from commons and that's the way it is used currently by a lot people. Most of
the time promotion of components take place because people are screaming for a release, even
though the component might not be ready, community wise or code wise. A possible user base
should not be a consideration for promotion.
At least put up a big disclaimer : use at own risk and if you really want to use it, build
it yourself.
- Let (*) people who work on components, improve communication (eg in todo's, future or ideas
kind of files in svn) to what they are thinking or what direction they want to see the component
go. This is more obvious with components that don't have a big developer base (fileupload
comes to mind, with just martinc active)  Not saying it isn't currently done this way, so
this is just a generalisation..
- Somehow keep track of committers actively involved / interested. Eg for betwixt the list
is pretty big, although I pretty much know for sure some people (ehh me) are not active on
the component. Maybe just adding active as a role to the project.xml and removing that when
not active anymore or moving the more active ones to the top ? Current people involved could
keep track of that list.
- See if some components can find a home in other projects. (jexl and el could nicely fit
in taglibs, though the project name taglibs probably needs some reconsideration if that is
going to happen).
- Create problem space groupings where possible (at least on the commons page).  eg 
servlet/jsp fileupload, jexl, el, email, validator, latka
java extensions (lang, collections, io)
xml (betwixt, digester, jelly
Grouping can be pretty hard to achieve in some cases and if I am not mistaking this was proposed
in the past.

(*) No forcing involved :)


Henri Yandell wrote:
> On 12/2/05, Martin Cooper <> wrote:
>>IMO, what this tells us is the Commons isn't scaling, and that doesn't
>>surprise me at all. In the "old days", there were a *lot* fewer components.
>>Right now, I count 35 components in Proper and 9 more active components in
>>the Sandbox (excluding the ones Henri is about to make dormant). That is a
>>lot of stuff! Very few people, if any, are going to keep tabs on all of it,
>>and most are likely to only track a handful, if that.
>>When Commons was much smaller, the community was much more integrated, in
>>that there was more overlap between the pieces (people-wise, not code-wise),
>>and so we all watched each others' backs. We're no longer in that state.
>>The inability to scale, is, in my opinion, an issue the ASF as a whole is
>>also facing. Unfortunately, as with Commons, I don't have any good ideas.
>>Other than to consciously stop growing, that is, but that doesn't appear to
>>be a popular direction.
> [long reply...sorry]
> Yep. It's my belief that Commons represents the ASF in microcosm, so
> trying to find solutions in Commons is a) easier than the whole ASF
> and b) useful to finding the whole ASF problem.
> I see two directions:
> 1) Hope a few more projects move out of Jakarta, then promote every
> Commons component to Jakarta subprojects and revolutionise Jakarta
> with some Commons concepts. It doesn't solve the problems, but it does
> accept that the components are increasingly being held up on the
> shoulders of 1 committer each, and makes us solve it at a Jakarta
> level, not a Commons level.
> 2) Reinvigorate ourselves as a community. The lip service is that
> we're all Commons committers and not individual component committers,
> but the reality is that not one of us is interested in 43+ components.
> We need to accept that and adapt.
> So I think we'd end up at 2) eventually even if 1) happens :)
> --
> So how can we rejuvenate a community without the mantra that we don't
> have focus?
> a) Work together. I don't mean that in a hippy peacenik way. I mean
> actually work together. We need to get a plan for the future of each
> component and then form groups attacking each target, but not at the
> same time.
> So Lang 2.2 might be held up because 3 of us need to work on
> Collections 2.2. Etc.
> b) Increase ease of bringing people into the community. Three problems
> to hit. 1) Encouraging people to get involved (it's hard). 2)
> Educating people. 3) Communication noise.
> b-1) is always hard. We encourage this mostly by being open and by
> broadcasting a sense of enjoyment. Another trick is to leave the easy
> jobs; don't gobble up easy fun bits (which is hard, they're fun :) ).
> b-2) is about making the information easier to find. We've a lot of it
> on the site etc, but we need to take the water more to the horse's
> mouth. So collating it into a single document etc is my aim.
> b-3) The mailing list is noisy. There are noisier out there, and it's
> nowhere near as noisy as it used to be, but increased components, and
> increased committers will mean it'll be noisier than ever. It's hard
> to see solutions here. SVN commit messages and Bugzilla messages are
> important, but so is not being accused of denial-of-service attacks :)
> One thought I had is to have a commons-sandbox-dev@ as well (Robert
> -1'd it when we talked on IRC :) ).
> c) Martin said it above.  "Very few are going to keep tabs on it".  We
> need a few people to keep tabs on it :)  Either by having very few who
> look at it all, or by using a hierarchy (ie grouping components). The
> board do this now, individual board members are tasked with following
> up on a project's report.
> d) Homogeneity. We may find we should decrease the independence of the
> components. They're pretty similar already, but I'm thinking that we
> could simplify the website a lot by moving away from Maven and having
> a Commons site, instead of individual Commons Xxx sites. This has a
> few advantages. It brings us together as a community more, it
> simplifies deploys that change the site, and it should make things a
> fair bit easier for readers of the site too.
> ---
> To make it all fun, we have to do this without turning it into a
> monotonous workplace.
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message