Re: Time for more mailing lists ?

[robert burrell donkin]

some observations (made in the spirit of Nicola's 'conceptual suggestions made as random thoughts')

email volume
------------
the high volume of email on this list deters some potential committers. IMHO it's manageable at the moment but maybe now is a good time to think about whether we could manage with many more components.

a single commons mailing list is good
-----------------------------------
i think that sharing a single mailing list is a GOOD THING. i think that it encourages people from different components to share ideas and come up with better solutions than they would in isolation. it also creates a collective spirit.

of course, it's quite possible to have too much of a good thing :)

sandbox components
------------------
sandbox components need to remain on the main commons list. these components would simply not be visible enough on other lists. this lack of visibility will make it even harder than now for these components to generate the momentum and the communities they need.

single component mailing lists
------------------------------
i think that single component mailing lists have not proved very successful.

not only are they unpopular with the components themselves but they are hard for outsiders to monitor. i (for one) have no idea about what's happening in httpclient and i cannot effectively supervise them.

when we decided to push them out onto their own list, i thought that all votes were supposed to remain on the main list. i don't recall seeing any VOTEs on this list about new committers or about releases. (i'm not saying that there's been any impropriety - just that if there was, there's no way that i'd know.)

if half a dozen components were pushed into their own mailing lists, then this could become an important issue.

conclusions
-----------
i don't like the idea of asking components to leave the main mailing list but i do think that this is something we'll have to face sooner or later.

i think that topic based lists are preferable to single component lists.

i think that these topics should be sufficiently broad to retain both the synergy that we have at the moment and the ability to collectively supervise the projects. new topic based mailing lists should not be created unless there will be a large enough community to make them viable.

i'd like the idea about all VOTEs taking place on a single list enforced.

possible component groupings
----------------------------

BeanUtils, CLI, Collections, Discovery, Lang, Logging should have enough momentum to a become a viable core grouping.

JXPath, jelly, betwixt, digester may be big enough to become a viable xml grouping

pool, DBCP could fit together into a cache group - but i think that it would be too small to be viable.

httpclient, latka, fileupload could fit together into a http group - but again, probably too small.

- robert


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