Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
Hey... I know what this could be called... Alexandria Henri Yandell wrote: On Wed, 15 Mar 2006, Stephen Colebourne wrote: Henri Yandell wrote: A joke turns into something serious ...but I am all with you guys. As I said: the more I think about it - the more I like the idea! You've got my +1 :) But is that what you mean? (+1 is active not passive) It is what I mean, though it's contextual (is for all of us). In my case it's: If someone were to dig into this and find or create a solution, I would actively test it, hassle infra/whomever, throw in ideas and do a little coding - but I'm not going to be much use if a large chunk of time to code/design is required. This all sounds like a nice idea, and could potentially solve the difficult issues and choices which we seem to be trying to make. But is it practical? Is there a tool out there that does this? Are there one or more people willing to drive this through and make it happen in the next three months? If its possible and is going to happen then we shouldn't do Jakarta Language Components. But if this idea isn't going to happen then JLC should be created. How will we make the decision? It's nice to talk - Robert's mentioned the idea in the past so it's good to have more brains thinking on the idea; however I wouldn't let it get in the way of simpler ideas for dealing with the current state. Presuming it involves a large buy in from the foundation - ie) not something we could do on our own - I'd factor in 6 months to a year to get that large a group moving :) Hen - 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]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On Wed, 15 Mar 2006, Stephen Colebourne wrote: Henri Yandell wrote: A joke turns into something serious ...but I am all with you guys. As I said: the more I think about it - the more I like the idea! You've got my +1 :) But is that what you mean? (+1 is active not passive) It is what I mean, though it's contextual (is for all of us). In my case it's: If someone were to dig into this and find or create a solution, I would actively test it, hassle infra/whomever, throw in ideas and do a little coding - but I'm not going to be much use if a large chunk of time to code/design is required. This all sounds like a nice idea, and could potentially solve the difficult issues and choices which we seem to be trying to make. But is it practical? Is there a tool out there that does this? Are there one or more people willing to drive this through and make it happen in the next three months? If its possible and is going to happen then we shouldn't do Jakarta Language Components. But if this idea isn't going to happen then JLC should be created. How will we make the decision? It's nice to talk - Robert's mentioned the idea in the past so it's good to have more brains thinking on the idea; however I wouldn't let it get in the way of simpler ideas for dealing with the current state. Presuming it involves a large buy in from the foundation - ie) not something we could do on our own - I'd factor in 6 months to a year to get that large a group moving :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
Henri Yandell wrote: A joke turns into something serious ...but I am all with you guys. As I said: the more I think about it - the more I like the idea! You've got my +1 :) But is that what you mean? (+1 is active not passive) This all sounds like a nice idea, and could potentially solve the difficult issues and choices which we seem to be trying to make. But is it practical? Is there a tool out there that does this? Are there one or more people willing to drive this through and make it happen in the next three months? If its possible and is going to happen then we shouldn't do Jakarta Language Components. But if this idea isn't going to happen then JLC should be created. How will we make the decision? Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On Wed, 15 Mar 2006, Torsten Curdt wrote: i like the idea of tagging emails better: a single list with cool server side filtering and metrics. we don't have the technology for this yet so i'm willing to see the mailing lists split so long as people would be willing to consider coming back if it every arrives... I was just considering proposing exactly this! A joke turns into something serious ...but I am all with you guys. As I said: the more I think about it - the more I like the idea! You've got my +1 :) This sort of functionality probably already exists in one of the open-source mailing list management packages; it isn't anything radical as far as I can see. Now we only have to find such a project and then convince infrastructure Ezmlm isn't loved over there as far as I can tell. It wouldn't have to deal with the major amount of spam that hits Apache - there's a mail server in front of the mailing list handler to take care of that, but there's still a lot of email flowing through. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On Wed, 15 Mar 2006, Torsten Curdt wrote: On 15.03.2006, at 10:10, Thomas Dudziak wrote: On 3/14/06, Torsten Curdt <[EMAIL PROTECTED]> wrote: ...regarding the forums - na. What does that help? Judging from myself, users don't like to have to subscribe to mailing lists, especially when they don't need the list on a daily basis. E.g. I would hate to get every question and answer in the Spring forums as mail. I'd much rather check the forums every once in a while. Use Gmane ;) I am too lazy to always go and check forums. With the tagging approach you would only have to really subscribe once. ...and as I said - having feeds would be awesome. I hate the fact I always have to subscribe to forums and never liked the interfaces. You misunderstood: Patrick told me that the 'special' feature of the system that they use at OpenQA is that it can be used both as a mailing list (e.g. for the developers) and a forum (for the users if you want). Therefore, you'd register at a mailing list just as before and have nothing to do at all with the forum-view, but users could instead use the forum (and thus won't get all the - for them - noise). And the system automatically maps between the mailing list and the forum. Basically Jive becomes a cool interface to the mailing list for those who like it - not an alternative set of threads. Patrick was showing it to me at ApacheCon - it seemed like a cool setup and he handled the various "What ifs" I threw at him (imagining the kinds of things that would come up on this list etc :) ). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On 15.03.2006, at 10:10, Thomas Dudziak wrote: On 3/14/06, Torsten Curdt <[EMAIL PROTECTED]> wrote: ...regarding the forums - na. What does that help? Judging from myself, users don't like to have to subscribe to mailing lists, especially when they don't need the list on a daily basis. E.g. I would hate to get every question and answer in the Spring forums as mail. I'd much rather check the forums every once in a while. Use Gmane ;) I am too lazy to always go and check forums. With the tagging approach you would only have to really subscribe once. ...and as I said - having feeds would be awesome. I hate the fact I always have to subscribe to forums and never liked the interfaces. You misunderstood: Patrick told me that the 'special' feature of the system that they use at OpenQA is that it can be used both as a mailing list (e.g. for the developers) and a forum (for the users if you want). Therefore, you'd register at a mailing list just as before and have nothing to do at all with the forum-view, but users could instead use the forum (and thus won't get all the - for them - noise). And the system automatically maps between the mailing list and the forum. I think what you are basically saying is you want a poll not a push service. IMO feeds are much better for that than a forum. But of course you could combine all these things. cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On 3/14/06, Torsten Curdt <[EMAIL PROTECTED]> wrote: > ...regarding the forums - na. What does that help? Judging from myself, users don't like to have to subscribe to mailing lists, especially when they don't need the list on a daily basis. E.g. I would hate to get every question and answer in the Spring forums as mail. I'd much rather check the forums every once in a while. > I hate the fact I always have to subscribe to forums and > never liked the interfaces. You misunderstood: Patrick told me that the 'special' feature of the system that they use at OpenQA is that it can be used both as a mailing list (e.g. for the developers) and a forum (for the users if you want). Therefore, you'd register at a mailing list just as before and have nothing to do at all with the forum-view, but users could instead use the forum (and thus won't get all the - for them - noise). And the system automatically maps between the mailing list and the forum. That being said, I don't know how powerful the system is, e.g. if it would support a 'schema' like the tagging used for the commons mailing list ([beanutils], [lang], etc.) and would be able to sort mails into the corresponding forums automagically. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
i like the idea of tagging emails better: a single list with cool server side filtering and metrics. we don't have the technology for this yet so i'm willing to see the mailing lists split so long as people would be willing to consider coming back if it every arrives... I was just considering proposing exactly this! A joke turns into something serious ...but I am all with you guys. As I said: the more I think about it - the more I like the idea! The another really cool feature with this tagging approach would be that cross-posting would no longer need to be banned - it would just not exist. A set of checkboxes would allow a user to "subscribe" to various lists, or to virtual groupings such as "jakarta commons" which would implicitly subscribe to the list for every project that is tagged as being a jakarta-commons project. Of course this implies fine-grained email lists (ie one for each project); the problems of partitioning the subscriber base too much is avoided by the existence of the groupings. Yepp! This system would allow overlapping groups to occur; for example commons-digester can be filed under both "commons" and "xml" virtual groups; someone subscribing to *either* group would receive digester-related emails. It also allows projects to move from one PMC to another without destroying the existing community (which *is* the set of people receiving emails). Great possibilites Groups also allow new projects to be created and added to the group; all people subscribed to the group would then automatically get emails related to that new project. Any list which has less than 3 subscribers would automatically forward its emails to the PMC list (or similar) for purposes of oversight. interesting Any person subscribed to 3 or more projects associated with "commons" would automatically be subscribed to the whole commons group (or maybe just sent a weekly nag email recommending they do so). That hopefully allows casual commons developers to get just postings for one or two projects, without destroying the useful commons-wide community that exists now. Having a single point for managing subscriptions would also help greatly with something that regularly frustrates me: suspending subscription when I'm away on holiday. Currently, I need to unsubscribe to half-a-dozen lists then resubscribe on return. Yepp! Another thing that would be awesome is to integrate it with a powerful archive system ...and then provide feeds for all the different tag combinations - and even individual threads! Man - that would be awesome! This sort of functionality probably already exists in one of the open-source mailing list management packages; it isn't anything radical as far as I can see. Now we only have to find such a project and then convince infrastructure ...regarding the forums - na. What does that help? I hate the fact I always have to subscribe to forums and never liked the interfaces. cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On 3/14/06, J Aaron Farr <[EMAIL PROTECTED]> wrote: > You mean like Nabble? (http://www.nabble.com) Though I recently migrated my project (Floyd) to OpenQA, I don't exactly know my way around there yet. But I think they are using Jive (http://www.jivesoftware.com/). cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On 3/14/06, Thomas Dudziak <[EMAIL PROTECTED]> wrote: > Perhaps a forum frontend would be even better for users, at least for > non-power-users. You mean like Nabble? (http://www.nabble.com) I like Simon's proposal. I know I need something that better allows me to manage the number of lists I'm on and a way to better filter converstations I'm interested in. Henri recently blogged something similar about a "mailing list client": http://blog.generationjava.com/roller/page/bayard?entry=to_gmail_or_not_to -- jaaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On 3/14/06, Thomas Dudziak <[EMAIL PROTECTED]> wrote: > On 3/14/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > > > I was just considering proposing exactly this! > > > > The issues about groupings, subprojects, etc. are completely irrelevant > > it seems to me. A community is the set of people subscribed to emails > > about a particular project, no more and no less. > > > > Unfortunately the way email lists are currently run at apache forces a > > strict hierarchy onto community structure, and forces a choice between > > coarse-grained and fine-grained style communities (eg one commons list > > vs one-per-project). PMCs are structured hierarchically, and that is > > reasonable, but communities don't need to be this way. > > > > The perfect system, to me, would be a website that allows a user to > > register a username/email-address; the process would confirm that the > > user's email address is valid. > > > > A set of checkboxes would allow a user to "subscribe" to various lists, > > or to virtual groupings such as "jakarta commons" which would implicitly > > subscribe to the list for every project that is tagged as being a > > jakarta-commons project. Of course this implies fine-grained email lists > > (ie one for each project); the problems of partitioning the subscriber > > base too much is avoided by the existence of the groupings. > > > > This system would allow overlapping groups to occur; for example > > commons-digester can be filed under both "commons" and "xml" virtual > > groups; someone subscribing to *either* group would receive > > digester-related emails. It also allows projects to move from one PMC > > to another without destroying the existing community (which *is* the set > > of people receiving emails). > > > > Groups also allow new projects to be created and added to the group; all > > people subscribed to the group would then automatically get emails > > related to that new project. > > > > Any list which has less than 3 subscribers would automatically forward > > its emails to the PMC list (or similar) for purposes of oversight. > > > > Any person subscribed to 3 or more projects associated with "commons" > > would automatically be subscribed to the whole commons group (or maybe > > just sent a weekly nag email recommending they do so). That hopefully > > allows casual commons developers to get just postings for one or two > > projects, without destroying the useful commons-wide community that > > exists now. > > > > Having a single point for managing subscriptions would also help greatly > > with something that regularly frustrates me: suspending subscription > > when I'm away on holiday. Currently, I need to unsubscribe to > > half-a-dozen lists then resubscribe on return. > > > > This sort of functionality probably already exists in one of the > > open-source mailing list management packages; it isn't anything radical > > as far as I can see. > > > Perhaps a forum frontend would be even better for users, at least for > non-power-users. > For instance, from what Patrick Lightbody told me about OpenQA, they > have a system that is both a forum and a mailing list: any forum entry > gets posted to the list, and any mail posted to the list appears in > the forum (e.g. see the Selenium forum at > http://forums.openqa.org/forum.jspa?forumID=3). > I haven't used it myself yet, but I could ask him if there is interest > in the technical details. That is a good idea. Forums don't work for extended team communication like mailing lists do. Mailing list don't work well for transient participants who only want to ask one question and then move on. You used to see this type of setup with mailing lists and news groups but news groups are all but dead to younger generations these days. -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On 3/14/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > I was just considering proposing exactly this! > > The issues about groupings, subprojects, etc. are completely irrelevant > it seems to me. A community is the set of people subscribed to emails > about a particular project, no more and no less. > > Unfortunately the way email lists are currently run at apache forces a > strict hierarchy onto community structure, and forces a choice between > coarse-grained and fine-grained style communities (eg one commons list > vs one-per-project). PMCs are structured hierarchically, and that is > reasonable, but communities don't need to be this way. > > The perfect system, to me, would be a website that allows a user to > register a username/email-address; the process would confirm that the > user's email address is valid. > > A set of checkboxes would allow a user to "subscribe" to various lists, > or to virtual groupings such as "jakarta commons" which would implicitly > subscribe to the list for every project that is tagged as being a > jakarta-commons project. Of course this implies fine-grained email lists > (ie one for each project); the problems of partitioning the subscriber > base too much is avoided by the existence of the groupings. > > This system would allow overlapping groups to occur; for example > commons-digester can be filed under both "commons" and "xml" virtual > groups; someone subscribing to *either* group would receive > digester-related emails. It also allows projects to move from one PMC > to another without destroying the existing community (which *is* the set > of people receiving emails). > > Groups also allow new projects to be created and added to the group; all > people subscribed to the group would then automatically get emails > related to that new project. > > Any list which has less than 3 subscribers would automatically forward > its emails to the PMC list (or similar) for purposes of oversight. > > Any person subscribed to 3 or more projects associated with "commons" > would automatically be subscribed to the whole commons group (or maybe > just sent a weekly nag email recommending they do so). That hopefully > allows casual commons developers to get just postings for one or two > projects, without destroying the useful commons-wide community that > exists now. > > Having a single point for managing subscriptions would also help greatly > with something that regularly frustrates me: suspending subscription > when I'm away on holiday. Currently, I need to unsubscribe to > half-a-dozen lists then resubscribe on return. > > This sort of functionality probably already exists in one of the > open-source mailing list management packages; it isn't anything radical > as far as I can see. Perhaps a forum frontend would be even better for users, at least for non-power-users. For instance, from what Patrick Lightbody told me about OpenQA, they have a system that is both a forum and a mailing list: any forum entry gets posted to the list, and any mail posted to the list appears in the forum (e.g. see the Selenium forum at http://forums.openqa.org/forum.jspa?forumID=3). I haven't used it myself yet, but I could ask him if there is interest in the technical details. cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Managing communities and emails (was Re: [PROPOSAL] Jakarta Language Components)
On Tue, 2006-03-14 at 20:23 +, robert burrell donkin wrote: > On Tue, 2006-03-07 at 19:13 +, Stephen Colebourne wrote: > > Reposted (edited) from original commons proposal. > > Currently this proposal has general, though not unanimous, support. > > A vote thread may follow this thread if the mood remains positive. > > i'm a little unsure whether this will turn out for better or worse but > if people out there have energy, i'm willing to give it a go. time's > probably right for a little innovation and experimentation. > > i like the idea of tagging emails better: a single list with cool server > side filtering and metrics. we don't have the technology for this yet so > i'm willing to see the mailing lists split so long as people would be > willing to consider coming back if it every arrives... I was just considering proposing exactly this! The issues about groupings, subprojects, etc. are completely irrelevant it seems to me. A community is the set of people subscribed to emails about a particular project, no more and no less. Unfortunately the way email lists are currently run at apache forces a strict hierarchy onto community structure, and forces a choice between coarse-grained and fine-grained style communities (eg one commons list vs one-per-project). PMCs are structured hierarchically, and that is reasonable, but communities don't need to be this way. The perfect system, to me, would be a website that allows a user to register a username/email-address; the process would confirm that the user's email address is valid. A set of checkboxes would allow a user to "subscribe" to various lists, or to virtual groupings such as "jakarta commons" which would implicitly subscribe to the list for every project that is tagged as being a jakarta-commons project. Of course this implies fine-grained email lists (ie one for each project); the problems of partitioning the subscriber base too much is avoided by the existence of the groupings. This system would allow overlapping groups to occur; for example commons-digester can be filed under both "commons" and "xml" virtual groups; someone subscribing to *either* group would receive digester-related emails. It also allows projects to move from one PMC to another without destroying the existing community (which *is* the set of people receiving emails). Groups also allow new projects to be created and added to the group; all people subscribed to the group would then automatically get emails related to that new project. Any list which has less than 3 subscribers would automatically forward its emails to the PMC list (or similar) for purposes of oversight. Any person subscribed to 3 or more projects associated with "commons" would automatically be subscribed to the whole commons group (or maybe just sent a weekly nag email recommending they do so). That hopefully allows casual commons developers to get just postings for one or two projects, without destroying the useful commons-wide community that exists now. Having a single point for managing subscriptions would also help greatly with something that regularly frustrates me: suspending subscription when I'm away on holiday. Currently, I need to unsubscribe to half-a-dozen lists then resubscribe on return. This sort of functionality probably already exists in one of the open-source mailing list management packages; it isn't anything radical as far as I can see. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
On Tue, 2006-03-14 at 15:29 -0500, Henri Yandell wrote: > Board report done - now I can irritate you all on these threads again :) > > On Tue, 14 Mar 2006, robert burrell donkin wrote: > >> - each component provides an extension to the JavaSE > >> - code judged by would it be out of place in the JavaSE > > > > probably the wrong test: some of the stuff that's included is pretty > > controversial and grows in scope all the time. i'm not sure that this is > > really what a lot of the extra rubbish is wanted: eg logging, crypto, > > sql, corba, swing. > > > > isn't it only really the lang, util, io and beans packages that are > > really of interest? > > +1. 'core of JavaSE' ? better :) nice'n'fuzzy > >> - have mailing lists (language-user/language-dev) > > > > is there any need for a another user list? > > Also, why cause users pain while we experiment. How about we do the -dev > list, and see how the -user list goes? > > > given smaller mail volumes and the nature of the audience for these > > components (java developers), i think it would be better to retain a > > common user list but encourage posting by users to the dev list. > > > > the commons was more active when there was no user lists. i'd like to > > propose we try that again for this new grouping. if a user list proves > > necessary then it can easily be added later. > > Ah. I thought you were suggesting that they would continue to use > commons-user. :) both at once, really :) any users who want to can use the commons-user list but not having a user list will encourage more people to subscribe to dev. which is a good thing. > I'm +1 to commons-user. I'm only +1 to not havin a user list if we get the > commits/wiki/jira out of the user's face. that'd be easy. might be better for oversight to have these posted to [EMAIL PROTECTED] anyway. > >> - not have a sandbox > > > > does that mean: use the jakarta sandbox if every needed? > > Pretty sure it does. > > >> - use [EMAIL PROTECTED] ML (new) for cross group issues > > > > general would feel better (to me) for discussing cross group issues but > > maybe dev might be needed for votes later... > > Yep. Re-word as: > > - use Jakarta wide lists for cross group issues. > > We can modify what those are if we think that general@ is overwhelmed by > Jakarta and we'd like it to be more pan-Apache Java or general-interest. +1 start here with the probably that we'll move later - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Board report done - now I can irritate you all on these threads again :) On Tue, 14 Mar 2006, robert burrell donkin wrote: On Tue, 2006-03-07 at 19:13 +, Stephen Colebourne wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. i'm a little unsure whether this will turn out for better or worse but if people out there have energy, i'm willing to give it a go. time's probably right for a little innovation and experimentation. i like the idea of tagging emails better: a single list with cool server side filtering and metrics. we don't have the technology for this yet so i'm willing to see the mailing lists split so long as people would be willing to consider coming back if it every arrives... I hereby propose the creation of a new Jakarta entity named 'Jakarta Language Components'. This will be formed from the following codebases: [lang] [io] [collections] - expected to divide [primitives] [codec] [id] - on exit from sandbox [beanutils] - logging to be removed The following are invited to join if their communities desire: [oro] [regexp] [cli] Jakarta Language Components mission: 'Enhancing Java SE' Jakarta Language Components will: - develop multiple independent components yep - each component will have no dependencies - each component will have no configuration perhaps a description may be better than a proscription: charters are bad since they need votes and formalism. groupings should be less formal and more social than sub-projects. Not sure if you're saying this, but +1 to having no formal charter - just an informal description. i think groupings will only work if the formal structures required (voting, karma, websites and so on) can be kept fixed and cross grouping so that groupings can be more fluid. +1 - each component provides an extension to the JavaSE - code judged by would it be out of place in the JavaSE probably the wrong test: some of the stuff that's included is pretty controversial and grows in scope all the time. i'm not sure that this is really what a lot of the extra rubbish is wanted: eg logging, crypto, sql, corba, swing. isn't it only really the lang, util, io and beans packages that are really of interest? +1. 'core of JavaSE' ? - a component typically has a broad API (many callable methods) - each method typically does relatively little processing KISS: not needed in a charter might be better to be descriptive: offer a separate positive description of an architypical component. this can be longer and can be amended more easily. grouping ethos document, perhaps? - have mailing lists (language-user/language-dev) is there any need for a another user list? Also, why cause users pain while we experiment. How about we do the -dev list, and see how the -user list goes? given smaller mail volumes and the nature of the audience for these components (java developers), i think it would be better to retain a common user list but encourage posting by users to the dev list. the commons was more active when there was no user lists. i'd like to propose we try that again for this new grouping. if a user list proves necessary then it can easily be added later. Ah. I thought you were suggesting that they would continue to use commons-user. :) I'm +1 to commons-user. I'm only +1 to not havin a user list if we get the commits/wiki/jira out of the user's face. - not have a sandbox does that mean: use the jakarta sandbox if every needed? Pretty sure it does. - use [EMAIL PROTECTED] ML (new) for cross group issues general would feel better (to me) for discussing cross group issues but maybe dev might be needed for votes later... Yep. Re-word as: - use Jakarta wide lists for cross group issues. We can modify what those are if we think that general@ is overwhelmed by Jakarta and we'd like it to be more pan-Apache Java or general-interest. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
On Tue, 2006-03-07 at 19:13 +, Stephen Colebourne wrote: > Reposted (edited) from original commons proposal. > Currently this proposal has general, though not unanimous, support. > A vote thread may follow this thread if the mood remains positive. i'm a little unsure whether this will turn out for better or worse but if people out there have energy, i'm willing to give it a go. time's probably right for a little innovation and experimentation. i like the idea of tagging emails better: a single list with cool server side filtering and metrics. we don't have the technology for this yet so i'm willing to see the mailing lists split so long as people would be willing to consider coming back if it every arrives... > I hereby propose the creation of a new Jakarta entity named 'Jakarta > Language Components'. > > This will be formed from the following codebases: > [lang] > [io] > [collections] - expected to divide > [primitives] > [codec] > [id] - on exit from sandbox > [beanutils] - logging to be removed > > The following are invited to join if their communities desire: > [oro] > [regexp] > [cli] > > Jakarta Language Components mission: > 'Enhancing Java SE' > > Jakarta Language Components will: > - develop multiple independent components yep > - each component will have no dependencies > - each component will have no configuration perhaps a description may be better than a proscription: charters are bad since they need votes and formalism. groupings should be less formal and more social than sub-projects. i think groupings will only work if the formal structures required (voting, karma, websites and so on) can be kept fixed and cross grouping so that groupings can be more fluid. > - each component provides an extension to the JavaSE > - code judged by would it be out of place in the JavaSE probably the wrong test: some of the stuff that's included is pretty controversial and grows in scope all the time. i'm not sure that this is really what a lot of the extra rubbish is wanted: eg logging, crypto, sql, corba, swing. isn't it only really the lang, util, io and beans packages that are really of interest? > - a component typically has a broad API (many callable methods) > - each method typically does relatively little processing KISS: not needed in a charter might be better to be descriptive: offer a separate positive description of an architypical component. this can be longer and can be amended more easily. grouping ethos document, perhaps? > - have mailing lists (language-user/language-dev) is there any need for a another user list? given smaller mail volumes and the nature of the audience for these components (java developers), i think it would be better to retain a common user list but encourage posting by users to the dev list. the commons was more active when there was no user lists. i'd like to propose we try that again for this new grouping. if a user list proves necessary then it can easily be added later. > - not have a sandbox does that mean: use the jakarta sandbox if every needed? > - use [EMAIL PROTECTED] ML (new) for cross group issues general would feel better (to me) for discussing cross group issues but maybe dev might be needed for votes later... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
I am generally +1. I think this is a good step in the right direction. On 3/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > > +1 > > The only negative is the dev@ as opposed to [EMAIL PROTECTED] > > Hen > > On Tue, 7 Mar 2006, Stephen Colebourne wrote: > > > Reposted (edited) from original commons proposal. > > Currently this proposal has general, though not unanimous, support. > > A vote thread may follow this thread if the mood remains positive. > > > > > > I hereby propose the creation of a new Jakarta entity named 'Jakarta > Language > > Components'. > > > > This will be formed from the following codebases: > > [lang] > > [io] > > [collections] - expected to divide > > [primitives] > > [codec] > > [id] - on exit from sandbox > > [beanutils] - logging to be removed > > > > The following are invited to join if their communities desire: > > [oro] > > [regexp] > > [cli] > > > > Jakarta Language Components mission: > > 'Enhancing Java SE' > > > > Jakarta Language Components will: > > - develop multiple independent components > > - each component will have no dependencies > > - each component will have no configuration > > - each component provides an extension to the JavaSE > > - code judged by would it be out of place in the JavaSE > > - a component typically has a broad API (many callable methods) > > - each method typically does relatively little processing > > - have mailing lists (language-user/language-dev) > > - not have a sandbox > > - use [EMAIL PROTECTED] ML (new) for cross group issues > > > > Stephen > > > > - > > 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] > > -- Steven Caswell [EMAIL PROTECTED] (c) 404-693-4148 (o) 404-260-2382 Take back the web - http://www.mozilla.org
Re: [PROPOSAL] Jakarta Language Components
Stephen Colebourne wrote: >>> other 1-word suggestions would be great. >> >> >> since they're language components, you can call them "Syllables" :-) > > > I understand the desire for 'fancy' names, but it misses the point > unfortunately. This is merely a grouping a several *Jakarta* components. Oh please - do I really have to spell it out? "Jakarta Syllables" Yoav asked for 1-word suggestions, so I wrote only one word. I think it perfectly catches the point of having a collection of tiny items, of which you combine several to create something that makes sense as a whole. > A fancy name should be thought of as implying TLP status. I don't get that, but it doesn't really matter. Somebody asked for suggestions, I provided one. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Stephen Colebourne wrote: Roland Weber wrote: Hello, other 1-word suggestions would be great. since they're language components, you can call them "Syllables" :-) I understand the desire for 'fancy' names, but it misses the point unfortunately. This is merely a grouping a several *Jakarta* components. A fancy name should be thought of as implying TLP status. +1 for the idea and also for the "bland" name - one of the things that I personally like about the I guess soon-to-be-defunct (sob, groan, choke j-c charter. Thanks, Stephen for pushing this forward. On the mailing list issue, I assume you mean we would have a jlc-dev, and jlc-user as well as the Jakarta-dev that you mention. Also, while this is technically [OT] here and probably deserves its own thread on j-c-dev, I would like to see [id] adopted as part of the formation of jlc - i.e., let it graduate into the new entity. Phil Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
+1 The only negative is the dev@ as opposed to [EMAIL PROTECTED] Hen On Tue, 7 Mar 2006, Stephen Colebourne wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. I hereby propose the creation of a new Jakarta entity named 'Jakarta Language Components'. This will be formed from the following codebases: [lang] [io] [collections] - expected to divide [primitives] [codec] [id] - on exit from sandbox [beanutils] - logging to be removed The following are invited to join if their communities desire: [oro] [regexp] [cli] Jakarta Language Components mission: 'Enhancing Java SE' Jakarta Language Components will: - develop multiple independent components - each component will have no dependencies - each component will have no configuration - each component provides an extension to the JavaSE - code judged by would it be out of place in the JavaSE - a component typically has a broad API (many callable methods) - each method typically does relatively little processing - have mailing lists (language-user/language-dev) - not have a sandbox - use [EMAIL PROTECTED] ML (new) for cross group issues Stephen - 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]
Re: [PROPOSAL] Jakarta Language Components
On 3/7/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote: > Stephen Colebourne wrote: > > Reposted (edited) from original commons proposal. > > Currently this proposal has general, though not unanimous, support. > > A vote thread may follow this thread if the mood remains positive. > > > > > ... > > > > Jakarta Language Components will: > > - develop multiple independent components > > I will vote -1 based soley on item 1 of the list for the reasons I've > already explained. I think that having ANOTHER jak-commons is a > fundementally bad idea. If these are truly enahancements to JavaSE, > they are one community, and share a mailinglist...then make them one > distribution and version them together. please correct me if i am off here, but my understanding is that this is not really "ANOTHER" commons. this is a proposal to pull out and group a subset of existing commons subprojects with the intent of simplifying and clarifying the current jumble that is commons. if anything, this looks to me like a step in the direction you are advocating. once like commons components are gathered together there may be potential to package them into one release. impeding it because it does not immediately go as far as you want it to seems picky. or do you really think these ought to be left alongside things like Jelly and ultimately packaged with them?? > > - each component will have no dependencies > > - each component will have no configuration > > - each component provides an extension to the JavaSE > > - code judged by would it be out of place in the JavaSE > > - a component typically has a broad API (many callable methods) > > - each method typically does relatively little processing > > - have mailing lists (language-user/language-dev) > > - not have a sandbox > > - use [EMAIL PROTECTED] ML (new) for cross group issues > > > > Stephen > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -Andy > > > - > 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]
Re: [PROPOSAL] Jakarta Language Components
Andrew C. Oliver wrote: I will vote -1 based soley on item 1 of the list for the reasons I've already explained. I think that having ANOTHER jak-commons is a fundementally bad idea. If these are truly enahancements to JavaSE, they are one community, and share a mailinglist...then make them one distribution and version them together. An interesting perspective. Firstly, this isn't another commons, but a breakout from the existing commons using the existing code in the existing packages. Secondly, jar hell is real and painful. We know that and strive for backwards compatibility. My hope is that this group will be able to create a single jar file in addition to the component jar files. Why? Because our users seem to want both. Thirdly, because it moves one step forward towards a world where Jakarta consists of lots of small components, each at the same level, grouped for communication, development and practicality. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
On 3/7/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > I hereby propose the creation of a new Jakarta entity named 'Jakarta > Language Components'. > > This will be formed from the following codebases: > [lang] > [io] > [collections] - expected to divide > [primitives] > [codec] > [id] - on exit from sandbox > [beanutils] - logging to be removed > > The following are invited to join if their communities desire: > [oro] > [regexp] > [cli] > > Jakarta Language Components mission: > 'Enhancing Java SE' > > Jakarta Language Components will: > - develop multiple independent components > - each component will have no dependencies > - each component will have no configuration > - each component provides an extension to the JavaSE > - code judged by would it be out of place in the JavaSE > - a component typically has a broad API (many callable methods) > - each method typically does relatively little processing > - have mailing lists (language-user/language-dev) > - not have a sandbox > - use [EMAIL PROTECTED] ML (new) for cross group issues Could you elaborate a bit on what the physical / visual-to-users differences to the current commons, well, Jakarta sub-project will be ? Will this be a new Jakarta sub-project (and the other commons components will remain in the current commons one) ? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Roland Weber wrote: Hello, other 1-word suggestions would be great. since they're language components, you can call them "Syllables" :-) I understand the desire for 'fancy' names, but it misses the point unfortunately. This is merely a grouping a several *Jakarta* components. A fancy name should be thought of as implying TLP status. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Hello, > other 1-word suggestions would be great. since they're language components, you can call them "Syllables" :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Andrew C. Oliver wrote: > Stephen Colebourne wrote: >> Reposted (edited) from original commons proposal. >> Currently this proposal has general, though not unanimous, support. >> A vote thread may follow this thread if the mood remains positive. >> >> > ... >> >> Jakarta Language Components will: >> - develop multiple independent components > > I will vote -1 based soley on item 1 of the list for the reasons I've > already explained. I think that having ANOTHER jak-commons is a > fundementally bad idea. If these are truly enahancements to JavaSE, > they are one community, and share a mailinglist...then make them one > distribution and version them together. See the list for how many users complain already now about the *size* of some of those components. Obviously these are often people from the J2ME camp or people dealing with applets. OTOH if a look at my last bigger app and the proposed list, I find only two of the packages, that I did not use. The problem with providing a combined jar of all and separated ones are again the dependencies, that will be a real mess then. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Stephen Colebourne wrote: Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. ... Jakarta Language Components will: - develop multiple independent components I will vote -1 based soley on item 1 of the list for the reasons I've already explained. I think that having ANOTHER jak-commons is a fundementally bad idea. If these are truly enahancements to JavaSE, they are one community, and share a mailinglist...then make them one distribution and version them together. - each component will have no dependencies - each component will have no configuration - each component provides an extension to the JavaSE - code judged by would it be out of place in the JavaSE - a component typically has a broad API (many callable methods) - each method typically does relatively little processing - have mailing lists (language-user/language-dev) - not have a sandbox - use [EMAIL PROTECTED] ML (new) for cross group issues Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta Language Components
Hola, General +1 to everything Stephen proposes, -0 on the name as previously discussed in another thread. Jorg's Jakarta Rocks is a good proposal, other 1-word suggestions would be great. I'll throw in a couple of simple ones from the same root idea: Augmento (Spanish for enhancing...) or Miglio (Italian, short for miglioramento)... Yoav On 3/7/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Reposted (edited) from original commons proposal. > Currently this proposal has general, though not unanimous, support. > A vote thread may follow this thread if the mood remains positive. > > > I hereby propose the creation of a new Jakarta entity named 'Jakarta > Language Components'. > > This will be formed from the following codebases: > [lang] > [io] > [collections] - expected to divide > [primitives] > [codec] > [id] - on exit from sandbox > [beanutils] - logging to be removed > > The following are invited to join if their communities desire: > [oro] > [regexp] > [cli] > > Jakarta Language Components mission: > 'Enhancing Java SE' > > Jakarta Language Components will: > - develop multiple independent components > - each component will have no dependencies > - each component will have no configuration > - each component provides an extension to the JavaSE > - code judged by would it be out of place in the JavaSE > - a component typically has a broad API (many callable methods) > - each method typically does relatively little processing > - have mailing lists (language-user/language-dev) > - not have a sandbox > - use [EMAIL PROTECTED] ML (new) for cross group issues > > Stephen > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Jakarta Language Components
Reposted (edited) from original commons proposal. Currently this proposal has general, though not unanimous, support. A vote thread may follow this thread if the mood remains positive. I hereby propose the creation of a new Jakarta entity named 'Jakarta Language Components'. This will be formed from the following codebases: [lang] [io] [collections] - expected to divide [primitives] [codec] [id] - on exit from sandbox [beanutils] - logging to be removed The following are invited to join if their communities desire: [oro] [regexp] [cli] Jakarta Language Components mission: 'Enhancing Java SE' Jakarta Language Components will: - develop multiple independent components - each component will have no dependencies - each component will have no configuration - each component provides an extension to the JavaSE - code judged by would it be out of place in the JavaSE - a component typically has a broad API (many callable methods) - each method typically does relatively little processing - have mailing lists (language-user/language-dev) - not have a sandbox - use [EMAIL PROTECTED] ML (new) for cross group issues Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
