Jeffrey Dever wrote:
Logical or not, these groupings are arbitrairy. Why enforce a grouping? Give users the finest granularity possible, and then they can choose their own group of lists to join based on their interests. And have trivial filtering to boot. If you REALLY wanted to have groupings, you could compose them from the fine grained lists. A meta list of lists as it were, where the meta list would subscribe to other lists and the users could subscribe to the meta lists or the fine grained lists as it suited them.As someone who is on alot of different apache lists, it tends to make sense to me to just extend that into commons, but is also the case that the crossover is important. Since httpclient got its own list, its involvement as a commons component has become less "exposed" to the group given its off on its own email list. It is easy to join the http list, but does it give us the crossover that benefits the commons so much? This issue is one of perspective:
-jsd
Jandalf
Jeff Dever
Perspective 1: Lots of discussion on the list associated with component X is not of interest to the rest of us, why do we have to see it.
Perspective 2: We really like to see whats going on in all the components, having interaction promotes interoperability.
Perspective 3: With one list it is difficult to search for specific content associated with one component without getting results for all the others.
I like Jeff's idea, but it seems there would be issues relating to responses going specifically to the meta-list or to the sub-lists?
How would one ensure that a response was made to the correct list?
Would messages always be "sent" by the users of the sub-lists with the meta-list only being for users "recieving" the emails?
This is all dependent on if this is actually possible.
Mark
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
