From: "Greg Stein" <[EMAIL PROTECTED]> > Let's plan out the *style* of multiple lists. But until we actually get the > components to fall into those lists, then let's defer their creation and > final specification. Stephen listed a bunch of components and a possible > breakdown, but we can't choose that UNTIL we know those components will > transfer themselves. And who knows what is going to arrive? I have zero > visibility into the assortment of Avalon, J-C, and XML reusable components. > > So I'm advocating "figure them out on-demand *as* new components arrive". > > Here we go: > > [ ] One mother general@ list, with specific breakouts when needed > [X] Per-concept mailing lists (define "concept" however) > [ ] Per-language mailing lists > [ ] ____________________________________________
My concepts are logically related groups of components. Core, Networking, XML, DB, GUI, Testing, Building. I'm trying to avoid listing too many, as that defeats the purpose of per-concept. (The purpose being that as small components, shared lists build a greater community) After some thought, I would accept cross language mailing lists, although I would prefer separate ones. It may be a case of starting with a cross language Networking list, and if the traffic gets too high splitting into per language lists. It might b a good way to get the community going. > > The exception comes if two languages share a mailing list. In that case CVS > > commit priveledges should probably be separated by language. > > I think commit privs should be per-component. I don't mind this. I just think its a big burden on those who can grant karma. Stephen
