Henri,
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.
Mark
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 [EMAIL PROTECTED]
* 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 <[EMAIL PROTECTED]> 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 [mailto:[EMAIL PROTECTED]
Good Morning,
Don Seiler <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
