commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Fortner <>
Subject Re: [All] Newbies and questioners: Please respect the policy of this list
Date Wed, 08 Feb 2006 23:36:15 GMT
My personal feeling is that choice is good.  Given the choice, I would 
probably subscribe to individual API lists rather than attempt to filter 
the messages that I get on this list as a previous poster suggested.

You mention that the benefit to having an all-inclusive list is that:
(1) People working on different APIs can see synergies or areas of 
commonality or need between the different groups.
(2) User subscriptions are easier.

While I agree with your first contention, I find that most of the people 
on the lists are actually users of the APIs not contributors.  So while 
it might be interesting to me as a VFS contributor to know that Net 
users might like to use some of its code, as a user this is largely 
irrelevant to me.  Also there's a lot of sharing going on outside of the 
Commons list that doesn't really get captured on the lists  or remains 
solely within the domain of the originating group.  For example, VFS has 
a number of Ant tasks that aren't distributed with Ant, but would 
actually be quite useful to Ant users.  This information is never really 
communicated out of the commons lists.

As for making user subscriptions easier.  Most people download the 
individual APIs that they want to use, and it makes sense for them to 
subscribe only to the list for that API. 

To sum up: if you're a lead on a project; subscribe to everything.  If 
you're a contributor or a user, you get a choice -- but contributors are 
encouraged to subscribe to everything. 


Henri Yandell wrote:
> There's a welcome mail? ;)
> Email overload is a general problem; the [foo] helps a bit but there
> has to be a time at which all being on the same list doesn't scale.
> Are commons-dev and commons-user fine currently? What if we fold all
> of the other Jakarta projects into them. Still fine?
> And yet there are huge benefits to sharing a list. Commons is all
> about huge crossover between tiny communities - but when does it go
> from being a constructive town meeting to becoming a bedlam of noise.
> Putting each component on its own -dev list would be death - so we
> obviously need a different solution there.
> However, it'd be interesting to hear what people think about the
> benefits of the -user list being shared. I see a few possibles:
> * Easy for users. They're not having to hunt down which mailing list a
> component is on - which will cause the kind of "sorry, please goto
> list such and such" redirects we often have to do on general@jakarta.
> * Not having a constant stream of mail list requests (and mail list
> removal requests).
> * Easier place to search (not that we make it that easy to search the lists).
> I'm not sure I'm convinced by any of them :) I'm also interested in
> whether a forum interface (working as a facade for the mailing list)
> would help. How are people finding nabble and gmane?
> Hopefully no one minds this navel-gazing; I'm always happy to reopen
> old discussions to see if the consensus has changed.
> Hen
> On 2/7/06, Martin van den Bemt <> wrote:
>> Can you (and preferrably others too) confirm that you actually read the (automated)
welcome mail ?
>> I never read them and my impression is that a lot of people don't read it.
>> Mvgr,
>> Martin
>> Hal Hildebrand wrote:
>>> It'd probably help if this policy was clearly spelled out in a welcome message
from the list.
>>>> -----Original Message-----
>>>> From: Boris Unckel []
>>>> Good Morning,
>>>> Don Seiler <>
>>>>> I was wondering earlier if it doesn't make sense to create individual
>>>>> user lists for the components?  Speaking from personal experience, I'm
>>>>> currently only interested in commons-net, and things like validator I
>>>>> could do without.
>>>> this is an old discussion (have a look at the archives). This was not my
>>>> point. As long as there is _one_ list and majority votes to have one list
>>>> people should respect that easy, understandable policy.
>>>> Regards
>>>> Boris
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message