I too have found j-c a little overwhelming recently, and now delete mails much quicker than I used to. This proposal pretty much covers what a-c needs to do to encurage transfers.
I suppose I object to #4, language agnostic, most. The coding I do in [lang] or [collections] strikes me as very java specific. But since there aren't any non-Java projects that I know of that would clash, I guess this group would probably become effectively Java only anyway. So, my proposed first group would be 'core'. This discussion has been controversial at j-c before, but there are probably some components that naturally fit this tag - [lang], [collections], [io]. Others could then be considered later. Other possible groupings: - xml - http/html/networking - database - enterprise - pooling The biggest problem will occur with components that don't naturally fit a group, or fit more than one. But having some kind of divide is going to be necessary. The one potential spanner in the works for me is subversion. When 99% of the world uses CVS, I really struggle with this one. Stephen ----- Original Message ----- From: "robert burrell donkin" <[EMAIL PROTECTED]> > the subject of encouraging products (both sub projects and components) to > move from jakarta to here has been raised before but without any real > positive outcome (at least that i can see). but (it seems to me that) the > board and members believe that a general movement of products from jakarta > would benefit everyone so probably at least one more effort is justified. > > > i've been thinking about these issues for a while now and i now think that > there's a chance now of gaining some momentum towards this goal. i believe > that there are lots of reasons why many products would benefit from a move > - even if they can't seem it yet ;) > > i believe that it would be possible to encourage this movement providing > that the right environment was provided for them. most people at jakarta > like busy mailing lists and like hanging out on the same list so they can > share ideas - even if this means enduring a massive quantity of email. > > jakarta-commons is reaching the limit of it's possible expansion (one > mailing list can only cope with so much traffic before it becomes > impossible - as my accumulated 1Gb of mail proves). i'd like to propose > that apache-commons creates organizational substructures inspired by the > jakarta-commons model each consisting of a group of related products so > that products will feel at home. > > > why do we need groups? > > i think that it's clear (from the un-rush) that jakarta products are not > beating down the doors of apache-commons demanding to be let in. if > apache-commons wants these products, it needs to offer encouragement. part > of this needs to be a friendly attitude and part demonstration of synergy > but i think also a sympathetic organization is important. > > > here's my list of characteristics for groups: > > 1. products would still be affiliated with jakarta (and retain links from > the jakarta site) but would be managed by the apache-commons pmc. > 2. products would be grouped together with other similar products to form > a group creating synergy. it should be easier to recruit new products > since this synergy would be much clear than the general 'apache-commons'. > 3, each group would have a name and a web page. each product within the > group would also have web pages organized underneath. > 4. each group would be language agnostic based upon a topic. > 5. it would be possible for groups to be promoted to top level project > status (given sufficient momentum). > 6. there would be one development mailing list for each group. > 7. there would be one user mailing list for each group but products would > be entitled to retain their existing user lists. > > - robert > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
