FW: RE: RE: Jakarta Overview
-Original Message- From: acoliver [mailto:[EMAIL PROTECTED]] -- I see a need for more integration documentation and top-down documentation. Jakarta isnt heirarchical, at all, and is in fact grossly federal, with member projects able to petition to join, cecede, be expelled. There are few federal laws, but many local ones which vary from project to project, and federal government in the form of the PMC does not represent all the interests of each project, or impose homogenaity(or whatever the word is!). Therefore federal documentation should limit itself to providing a map of the member projects, and the location their own documnetation. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FW: RE: RE: Jakarta Overview
I should draw you a diagram of new federalism it would wreck your mind... ;-) On Sat, 2002-03-23 at 05:07, Danny Angus wrote: -Original Message- From: acoliver [mailto:[EMAIL PROTECTED]] -- I see a need for more integration documentation and top-down documentation. Jakarta isnt heirarchical, at all, and is in fact grossly federal, with member projects able to petition to join, cecede, be expelled. There are few federal laws, but many local ones which vary from project to project, and federal government in the form of the PMC does not represent all the interests of each project, or impose homogenaity(or whatever the word is!). Therefore federal documentation should limit itself to providing a map of the member projects, and the location their own documnetation. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
On Wed, 20 Mar 2002, Waldhoff, Rodney wrote: | Well said Andrew. | | Re. Chris's point, I think we'll be hard pressed to reach consensus on what | a project maturity means, let alone how to measure it. | | If I were building this document (and if I remember correctly, I built this | document: http://jakarta.apache.org/commons/components.html, which is rather | similiar in some respects), I'd stick to factual information--brief | description, release dates/numbers, etc. and let the facts speak for | themselves. As those numbers are pretty different from project to project, I think that's not very indicative (?). # downloads is _interesting_, but of course it doesn't say very much. But it _is_ interesting and does actually say something about the combination of usability (audience) * maturity. Regarding Ted's comments about large user base being bad: that's just to weird. A large user base WILL make a product better. The worst thing that can happen to a product is that the developers sits inside their tech-box and just develops cool shit. The _usability_ of the product must always be in front. And there you have the users. And the users of these products most often being developers themselves will give the product more development, guaranteed. There _are_ itches that's just so annoying that even I will try to fix them... -- Mvh, Endre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
On Wed, 20 Mar 2002, Ceki Gülcü wrote: | | Isn't the overview document trying to substitute itself for the | documentation that is already in subprojects (or should be)? No. It's an overview of what's inside of jakarta. Great! | The cornerstone of the Jakarta and Apache Software Foundation in | general is that management delegates responsibility for a given | subproject to each subproject, intervening as little as possible. | | Your introduction also raises further worries. Jakarta does not need | more publicity. Everybody knows Jakarta. What is needed is improving | the quality of each *subproject*. Marketing gimmicks are not helpful and just | waste precious time. I don't agree. I still haven't browsed around all those projects and subprojects. I think this idea is great. Give me a two-line lowdown of what the stuff is, so that I can decide whether it is worth clicking on for my own part. Jakarta's cryptic names doesn't exactly say much, do they? | | More importantly, who is to decide what project has what maturity? I find | the overview document a little too interventionist, perhaps less in content | than in sprit. Until these concerns are addressed, here is my -1. Why not put it in the public and see what happens?? [btw: WHY don't people cut away the shit they don't reply to?? It's SO annoying.. ] -- Mvh, Endre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Give me a two-line lowdown of what the stuff is, so that I can decide whether it is worth clicking on for my own part. Jakarta's cryptic names doesn't exactly say much, do they? Try and look at the front page for, admittedly a one liner, but one without subjective overtones, which doesn't present a non-contributors view of many projects as the Jakarta Overview Definition of what the project is. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Danny Angus wrote: Try and look at the front page for, admittedly a one liner, but one without subjective overtones, which doesn't present a non-contributors view of many projects as the Jakarta Overview Definition of what the project is. The overview has been donated to the ASF, and is under Jakarta rules now. If anyone wants to make it more objective, have at it. If not, leave it alone and it will wither away. Regardless of the content, it's important to recognize that the initial author Did The Right Thing. The overview was prepared in XML and required no afterwork to commit. This makes him a Contributor in my book. If more of our users went to the trouble this person went to, we'd have more and better documentation throughout Jakarta. We are very quick to say Thanks for Volunteering around here. OK, someone volunteered, and we got what we wished for. Apache stands for patching ... -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
The overview has been donated to the ASF, and is under Jakarta rules now. If anyone wants to make it more objective, have at it. If not, leave it alone and it will wither away. Regardless of the content, it's important to recognize that the initial author Did The Right Thing. The overview was prepared in XML and required no afterwork to commit. This makes him a Contributor in my book. If more of our users went to the trouble this person went to, we'd have more and better documentation throughout Jakarta. We are very quick to say Thanks for Volunteering around here. OK, someone volunteered, and we got what we wished for. Apache stands for patching ... Well said friend, I totally agree! -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Ted, I don't want to have an argument, and I'm not criticising Philipp for offering, nor for the effort he obviously put in. I do have some reservations with this particular page, which I'm not going to raise again, if anyones interested they've already read them. I would like to take you up on a couple of points you make though, The overview has been donated to the ASF, and is under Jakarta rules now. Does this mean that anything donated is accepted on behalf of the project, by anyone with karma, without discussion and can therefore only be openly opposed once it has already been accepted? If anyone wants to make it more objective, have at it. If not, leave it alone and it will wither away. What if (and I don't, I'm just asking) modification and inaction are not enough for me, I want to veto it? I don't have enough Karma for Jakarta-site2, but if I did would I be within my rights to arbitrarily remove it? I think, and hope, not. Therefore it seems that it is a bigger hurdle for a donation of this kind to be vetoed than accepted. Regardless of the content, it's important to recognize that the initial author Did The Right Thing. The overview was prepared in XML and required no afterwork to commit. This makes him a Contributor in my book. If more of our users went to the trouble this person went to, we'd have more and better documentation throughout Jakarta. You're absolutely right, I agree utterly with that statement, and I hope my miserable grumping doesn't put him off. Apache stands for patching ... But we don't want to have to patch any old thing that comes swinging by, do we? Surely there could be a slightly better, and simple, way of accepting website proposals that makes it obvious that they are undergoing peer review? And in the interests of providing construtive criticism I'll propose -- A proposals section of the site, into which anyone with karma can commit any submissions and from which documents can be promoted by lazy concensus of all jakarta commiters. Its stylesheet will include a footer explaining the status of proposal documents(if thats possible). -- for instance? d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
I'm not Ted, but let me take a stab. :) - Original Message - From: Danny Angus [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Friday, March 22, 2002 7:09 AM Subject: RE: Jakarta Overview Ted, I don't want to have an argument, and I'm not criticising Philipp for offering, nor for the effort he obviously put in. I do have some reservations with this particular page, which I'm not going to raise again, if anyones interested they've already read them. I would like to take you up on a couple of points you make though, The overview has been donated to the ASF, and is under Jakarta rules now. Does this mean that anything donated is accepted on behalf of the project, by anyone with karma, without discussion and can therefore only be openly opposed once it has already been accepted? Yes, that is the Commit Then Review philosophy. You cannot prevent anyone from initially committing anything, but one it has been committed you can vote it down. If anyone wants to make it more objective, have at it. If not, leave it alone and it will wither away. What if (and I don't, I'm just asking) modification and inaction are not enough for me, I want to veto it? I don't have enough Karma for Jakarta-site2, but if I did would I be within my rights to arbitrarily remove it? I think, and hope, not. Therefore it seems that it is a bigger hurdle for a donation of this kind to be vetoed than accepted. You cannot arbitrarily remove it, but you can veto it. Under the current, slightly strange, default voting rules for Jakarta, Ted would have to talk you out of your objection; if he could not, he might have to back out his change (or you could do it for him). Any changes to a product require consensus approval. Does the website fit under the definition of a Jakarta product? A good question, which does not come up very often. Usually committers are more permissive of website changes then code changes. Regardless of the content, it's important to recognize that the initial author Did The Right Thing. The overview was prepared in XML and required no afterwork to commit. This makes him a Contributor in my book. If more of our users went to the trouble this person went to, we'd have more and better documentation throughout Jakarta. You're absolutely right, I agree utterly with that statement, and I hope my miserable grumping doesn't put him off. Apache stands for patching ... But we don't want to have to patch any old thing that comes swinging by, do we? Surely there could be a slightly better, and simple, way of accepting website proposals that makes it obvious that they are undergoing peer review? Well you can always exercise your veto. Then the committer backs it out, discusses changes on the list, makes some modifications, and resubmits for another vote. And in the interests of providing construtive criticism I'll propose -- A proposals section of the site, into which anyone with karma can commit any submissions and from which documents can be promoted by lazy concensus of all jakarta commiters. Its stylesheet will include a footer explaining the status of proposal documents(if thats possible). -- for instance? d. We have that section. It's called CVS. :) It operates exactly the way you describe. - Morgan _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
On Friday, March 22, 2002, at 01:09 PM, Danny Angus wrote: snip And in the interests of providing construtive criticism I'll propose -- A proposals section of the site, into which anyone with karma can commit any submissions and from which documents can be promoted by lazy concensus of all jakarta commiters. Its stylesheet will include a footer explaining the status of proposal documents(if thats possible). -- for instance? without wanting to sink the idea (even though it might), it's not clear how lazy consensus works (even at the moment) as far as the site goes. is it everyone with jakarta-site karma, is it all committers or is it just the PMC? the voting processing for the site would need to be clarified before we could even think about creating a system that uses that it. conversely if we find that we aren't able to get the community momentum required to clarify the process then the system will be built on sand. - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Hi, I'll try not to keep banging on about this, I know its not that important in the great scheme of Why We Are Here :-) but .. Yes, that is the Commit Then Review philosophy. You cannot prevent anyone from initially committing anything, but one it has been committed you can vote it down. Ok, thats fair enough. Any changes to a product require consensus approval. Does the website fit under the definition of a Jakarta product? A good question, which does not come up very often. Usually committers are more permissive of website changes then code changes. The issue for me is that the website is in a perpetual state of releasing the head of cvs every time a change is made, there is no un-released development state for the website, and while there is arguably a conceptual pre-release state while things are being reviewed it isn't clear to people who don't know our ways that some documents may carry the full weight of approval, or be Rules, or Codes of Conduct, yet others, undifferentiated, are merely proposals and possibly contentious at that. [The PMC should, of course, have unfettered right to publish. Its part of their role.] We have that section. It's called CVS. :) It operates exactly the way you describe. Not if the head is going to be built and released everytime someone commits something new. and if it isnt then its harder for people to review new material. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Morgan, Your point about trust is well made, I think that its is the straw I was grasping for! I seem to have temporarily overlooked the fact that this whole edifice is glued together by trust already, and to not have a more explicit mechanism regarding the website made me neglect that.. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: Jakarta Overview
Andy, Another good point, I do seem to have taken a robustly negative view of all this. Perhaps too much so. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
- there's too many committers in jakarta to get 'em all to vote on jakarta-site2. Pointless waste of energy, imho. - committers are responsible people (or they should be, at least!) - as a whole, open source lacks docs. So does Jakarta. For those that disagree: look at sensible-documentation-per- api-method at msdn.microsoft.com, then look at us. - many people monitor the site and its changes. The points above lead me to believe the current (lack of rigid) system is the right one. And I do think we all agree that the jakarta site should be as objective as possible. regards, - Leo Simons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ceki Gulcu Sent: 20 March 2002 10:27 To: Jakarta General List Subject: Re: Jakarta Overview Isn't the overview document trying to substitute itself for the documentation that is already in subprojects (or should be)? The cornerstone of the Jakarta and Apache Software Foundation in general is that management delegates responsibility for a given subproject to each subproject, intervening as little as possible. Your introduction also raises further worries. Jakarta does not need more publicity. Everybody knows Jakarta. What is needed is improving the quality of each *subproject*. Marketing gimmicks are not helpful and just waste precious time. More importantly, who is to decide what project has what maturity? I find the overview document a little too interventionist, perhaps less in content than in sprit. Until these concerns are addressed, here is my -1. At 16:36 18.03.2002 -0800, you wrote: Greetings! I have been following some of the recent discussions on this mailing list about possible directions for the Jakarta project. I would like to offer the following observation: To have code and projects coming out of Jakarta being more widely adopted, developers first need to be aware of them, then they have to be able to judge whether a Jakarta project is suitable for the developers' needs. I believe that the Jakarta website could do more to make its products easily accessible. It is often not easy to tell what a project is actually about, what the project's scope is, how its functionality is achieved, or how mature and usable the existing code base is. Evaluating an of-the-shelf component usually is an iterative process: In a first step one tries to determine the overall purpose of the component, and whether it is suitable for one's purpose at all. In later steps, one may consider how the component works, and what distinguishes it from comparable/competing products. The Jakarta subprojects support this evaluation and decision process to various degrees. The one that I am most familiar with (Velocity) is exceptional in this regard (mere coincidence?). But some (sub-)projects force the potential user to study the Javadoc to find out which problem the project attempts to solve, which is probably unacceptable for many visitors. I think it would be helpful for everyone (in particular in light of the desire to see Jakarta code being more widely adopted in outside projects) to try to improve the information offered here, and to support visitors in their evaluation and decision process as much as possible. After this introduction... Here is what I have done: I have scoured the entire Jakarta website and compiled information not only on each project, but also on each of the subprojects (such as those in the Commons, or those that are part of Avalon or Turbine), which are not immediately visible when visiting the Jakarta homepage. For each project, I have included a short, one-paragraph description (often taken from the projects webpage), but I also tried to give a sense of the maturity and the activity of the project. For anybody wanting to use (as opposed to develop) Jakarta code in their own projects, this information will play a significant part in their final decision. (I report the version number as proxy for the maturity and the extend of the News section of each project as proxy for its activity.) I hope that by providing the information not only about the top level project, but also about all the individual subprojects in one location, a visitor to the site will have an easier time assessing purpose and scope of each of the projects. I would hope that this can be extended in the future to include the following: - a concise abstract, stating what the project is about and what purpose it serves (the foundation for which I hope to provide here, based on what many projects already offer on their individual homepages) - a description how the project works, possibly by walking the visitor through a Hello, world example
RE: Jakarta Overview
Perhaps you could become a Jakarta developer by altering the provided overview so that it is both useful to users and acceptable to the developers of the projects it covers. I should say a subjective (mature/immature/good/bad) information might be useful, but probably is more the area of a Jakarta fan-site ;-) then the Jakarta site itself. Furthermore, just a personal opinion, Documentation is an area I truly want to help improve at Jakarta as a whole. But, one thing I've noticed is that it is much easier to contribute documentation at the project level and work your way up then vice versa. I like the overview myself, its a clear and gives folks an easier way to find what they need. I yet understand the concerns about keeping it up to date and the likes. My suggestion is though is too fold. General tends to give new contributers who read the literature about community and the likes a trial by incident, a series of -1 no I don't like it! and depend upon the contributer to climb the mountain. Rough for a first timer. Perhaps trying to be a bit more positive and saying good but have you considered instead of the more traditional approach. ;-) Secondly, to the contributer of said documentation and future contributers. While end to end documentation is seriously lacking, I suggest contributing to the in developing Jakarta Manual and furthermore the lower level project documentation first. Try not to include too much subjective information (cause for debate) and don't take it personally ;-) or anything anywhere at anytime too seriously. (air raids and the likes excluded) -Andy On Wed, 2002-03-20 at 05:35, Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ceki Gulcu Sent: 20 March 2002 10:27 To: Jakarta General List Subject: Re: Jakarta Overview Isn't the overview document trying to substitute itself for the documentation that is already in subprojects (or should be)? The cornerstone of the Jakarta and Apache Software Foundation in general is that management delegates responsibility for a given subproject to each subproject, intervening as little as possible. Your introduction also raises further worries. Jakarta does not need more publicity. Everybody knows Jakarta. What is needed is improving the quality of each *subproject*. Marketing gimmicks are not helpful and just waste precious time. More importantly, who is to decide what project has what maturity? I find the overview document a little too interventionist, perhaps less in content than in sprit. Until these concerns are addressed, here is my -1. At 16:36 18.03.2002 -0800, you wrote: Greetings! I have been following some of the recent discussions on this mailing list about possible directions for the Jakarta project. I would like to offer the following observation: To have code and projects coming out of Jakarta being more widely adopted, developers first need to be aware of them, then they have to be able to judge whether a Jakarta project is suitable for the developers' needs. I believe that the Jakarta website could do more to make its products easily accessible. It is often not easy to tell what a project is actually about, what the project's scope is, how its functionality is achieved, or how mature and usable the existing code base is. Evaluating an of-the-shelf component usually is an iterative process: In a first step one tries to determine the overall purpose of the component, and whether it is suitable for one's purpose at all. In later steps, one may consider how the component works, and what distinguishes it from comparable/competing products. The Jakarta subprojects support this evaluation and decision process to various degrees. The one that I am most familiar with (Velocity) is exceptional in this regard (mere coincidence?). But some (sub-)projects force the potential user to study the Javadoc to find out which problem the project attempts to solve, which is probably unacceptable for many
Re: Jakarta Overview
Jakarta is developer-centric because developers are the ones who volunteer to do the work. They need working products to use with their paying jobs, and find that sharing the development load works better than going it alone. We don't get many marketing volunteers because there is very little payback. More marketing generates more users, but that doesn't always translate into more development or better products. Sometimes more users can actually hurt development, since user support distracts developers from developing. (Only so many cycles in a day.) I do a lot of work on product documentation myself, mostly becuase I have a mind like a sieve, and need it for my own reference. But for most developers and users, there is less of a payback, since once they know the product they don't feel the need to document it for their own use. Jakarta is here to build products. If someone wants to market those products, that's great. If volunteers want to provide commit-ready documentation, like Phillip did, I'll fulfill my responsibility as a committer, and post it. But the problem now is, who's going to maintain it over the long run? If the developers want to, that's great, but if they don't, well, how the other committers spend their volunteer hours is up to them. So, sure, some clear exposition about Jakarta would help a lot of people. If someone has an itch for more documentation, they should create it and share it with the group in a ready-to-commit format, as Phillip did. Though, I'm sure anyone ready to do the work doesn't need someone else to suggest the idea. Jakarta cannot be anything by design; it can only be what the volunteers make it. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Web: http://husted.com/struts Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Well said Andrew. Re. Chris's point, I think we'll be hard pressed to reach consensus on what a project maturity means, let alone how to measure it. If I were building this document (and if I remember correctly, I built this document: http://jakarta.apache.org/commons/components.html, which is rather similiar in some respects), I'd stick to factual information--brief description, release dates/numbers, etc. and let the facts speak for themselves. -Original Message- From: Andrew C. Oliver To: Jakarta General List Sent: 3/20/2002 6:27 AM Subject: RE: Jakarta Overview Perhaps you could become a Jakarta developer by altering the provided overview so that it is both useful to users and acceptable to the developers of the projects it covers. I should say a subjective (mature/immature/good/bad) information might be useful, but probably is more the area of a Jakarta fan-site ;-) then the Jakarta site itself. Furthermore, just a personal opinion, Documentation is an area I truly want to help improve at Jakarta as a whole. But, one thing I've noticed is that it is much easier to contribute documentation at the project level and work your way up then vice versa. I like the overview myself, its a clear and gives folks an easier way to find what they need. I yet understand the concerns about keeping it up to date and the likes. My suggestion is though is too fold. General tends to give new contributers who read the literature about community and the likes a trial by incident, a series of -1 no I don't like it! and depend upon the contributer to climb the mountain. Rough for a first timer. Perhaps trying to be a bit more positive and saying good but have you considered instead of the more traditional approach. ;-) Secondly, to the contributer of said documentation and future contributers. While end to end documentation is seriously lacking, I suggest contributing to the in developing Jakarta Manual and furthermore the lower level project documentation first. Try not to include too much subjective information (cause for debate) and don't take it personally ;-) or anything anywhere at anytime too seriously. (air raids and the likes excluded) -Andy On Wed, 2002-03-20 at 05:35, Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ceki Gulcu Sent: 20 March 2002 10:27 To: Jakarta General List Subject: Re: Jakarta Overview Isn't the overview document trying to substitute itself for the documentation that is already in subprojects (or should be)? The cornerstone of the Jakarta and Apache Software Foundation in general is that management delegates responsibility for a given subproject to each subproject, intervening as little as possible. Your introduction also raises further worries. Jakarta does not need more publicity. Everybody knows Jakarta. What is needed is improving the quality of each *subproject*. Marketing gimmicks are not helpful and just waste precious time. More importantly, who is to decide what project has what maturity? I find the overview document a little too interventionist, perhaps less in content than in sprit. Until these concerns are addressed, here is my -1. At 16:36 18.03.2002 -0800, you wrote: snip snip
Re: Jakarta Overview
Waldhoff, Rodney [EMAIL PROTECTED] writes: Re. Chris's point, I think we'll be hard pressed to reach consensus on what a project maturity means, let alone how to measure it. If I were building this document (and if I remember correctly, I built this document: http://jakarta.apache.org/commons/components.html, which is rather similiar in some respects), I'd stick to factual information--brief description, release dates/numbers, etc. and let the facts speak for themselves. +1 -- sticking to the facts leaves the evaluation of a package up to the consumer. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Nice docs, care to explain some things: Philipp K. Janert [EMAIL PROTECTED] wrote on 19/03/2002 11:36:35 AM: [snip] significant part in their final decision. (I report the version number as proxy for the maturity and the extend of the News section of each project as proxy for its activity.) [snip] I know for the stuff I do, 'News' is the least correct indicator of activity on a project. Much can happen on a project that developers don't find 'newsworthy', e.g. documentation. [snip] libDocumentation:nbsp;/bOverview, Javadoc, and XML syntax reference, documentation appears somewhat immature/li [snip] Can you clear up how the documentation appears somewhat immature for Latka? [snip] -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://www.multitask.com.au/developers
RE: Jakarta Overview
In order to avoid duplicate edits, can we just point the Commons section of this document to: http://jakarta.apache.org/commons/components.html -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 4:49 AM To: Jakarta General List Subject: Re: Jakarta Overview http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
The concept of this document is perhaps a good one, but can you clarify how its role is distinct from the Jakarta Subprojects section of the homepage? Also, I take a bit of exception to the Documentation: None classification on commons-pool and commons-dbcp. The documentation is minimal, no doubt, and likely insufficient, but none suggests there's no need to keep looking for it, while if you do, you'll find fairly extensive JavaDocs: * http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/ind ex.html * http://nagoya.apache.org/gump/javadoc/jakarta-commons/dbcp/dist/docs/api/ind ex.html as well as some additional documentation for each: * http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/doc/ * http://cvs.apache.org/viewcvs/jakarta-commons/pool/xdocs/ And I'll reiterate dion's comment: Documentation: Overview, Javadoc, and XML syntax reference, That seems pretty exhaustive for what Latka does.
RE: Jakarta Overview
Hi all, It feels like Philipp has a downer on javadocs, perhaps he should contribute docs to those projects he feels are inadequate rather than just criticising, how many offers of documention contributions do the various projects receive compared to actual submissions? It also reads as a pretty personal opinion of whats here, it would surely be better placed on a site which comments/observes/criticizes jakarta than the jakarta site? And anyway .. this information is all here already, the projects all maintain their descriptions worded as the contributors choose, I think project descriptions belong on their homepages, with the brief description on the homepage which I think seems fine as it is. d. Just my 2p. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re: Jakarta Overview
+1 - I'd like to see the detractors patch it as they see fit. On Tue, 19 Mar 2002 08:56:31 -0800 Daniel Rall [EMAIL PROTECTED] wrote. Ted Husted [EMAIL PROTECTED] writes: http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. I would be in favor of having the overview linked off of the About Jakarta section of the left nav. Index: project.xml === RCS file: /home/cvs/jakarta-site2/xdocs/stylesheets/project.xml,v retrieving revision 1.28 diff -u -u -r1.28 project.xml --- project.xml17 Mar 2002 11:20:42 - 1.28 project.xml19 Mar 2002 16:55:55 - @@ -17,6 17,7 @@ menu name=About Jakarta item name=Welcome href=/index.html/ item name=News Status href=/site/news.html/ item name=Overview href=/site/overview.html/ item name=Our Mission href=/site/mission.html/ item name=Our FAQs href=/site/faqs.html/ item name=Reference Library href=/site/library.html/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Jakarta Overview
I'm -1 until someone can clarify how/why this is different from the Jakarta Subprojects section of the home page. Why not just add status information to that listing, if that's where the value-add is? How many places do we expect developers to update/document the status of their projects? -Original Message- From: acoliver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 11:16 AM To: [EMAIL PROTECTED] Subject: Re: Re: Jakarta Overview +1 - I'd like to see the detractors patch it as they see fit. On Tue, 19 Mar 2002 08:56:31 -0800 Daniel Rall [EMAIL PROTECTED] wrote. Ted Husted [EMAIL PROTECTED] writes: http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. I would be in favor of having the overview linked off of the About Jakarta section of the left nav. Index: project.xml === RCS file: /home/cvs/jakarta-site2/xdocs/stylesheets/project.xml,v retrieving revision 1.28 diff -u -u -r1.28 project.xml --- project.xml17 Mar 2002 11:20:42 - 1.28 project.xml19 Mar 2002 16:55:55 - @@ -17,6 17,7 @@ menu name=About Jakarta item name=Welcome href=/index.html/ item name=News Status href=/site/news.html/ item name=Overview href=/site/overview.html/ item name=Our Mission href=/site/mission.html/ item name=Our FAQs href=/site/faqs.html/ item name=Reference Library href=/site/library.html/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Ted Husted [EMAIL PROTECTED] writes: http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. I would be in favor of having the overview linked off of the About Jakarta section of the left nav. Index: project.xml === RCS file: /home/cvs/jakarta-site2/xdocs/stylesheets/project.xml,v retrieving revision 1.28 diff -u -u -r1.28 project.xml --- project.xml 17 Mar 2002 11:20:42 - 1.28 +++ project.xml 19 Mar 2002 16:55:55 - @@ -17,6 +17,7 @@ menu name=About Jakarta item name=Welcome href=/index.html/ item name=News amp; Status href=/site/news.html/ +item name=Overview href=/site/overview.html/ item name=Our Mission href=/site/mission.html/ item name=Our FAQs href=/site/faqs.html/ item name=Reference Library href=/site/library.html/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
On Tue, 2002-03-19 at 18:01, Daniel Rall wrote: Waldhoff, Rodney [EMAIL PROTECTED] writes: I'm -1 until someone can clarify how/why this is different from the Jakarta Subprojects section of the home page. One difference that I've noticed is that overview.xml is a more complete and comprehensive list of projects, where as the Subprojects section is missing quite a few -- I speculate that it may only be listing first-tier Jakarta projects, rather than their sub-projects as well (which are often times quite different and worth listing somewhere other than the home page of the first-tier projects). Why not just add status information to that listing, if that's where the value-add is? How many places do we expect developers to update/document the status of their projects? seems like a good place for some kind of include facility I'm no such a fan of the status information myself, but really like the comprehensive listing. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Jakarta Overview
On Tue, 2002-03-19 at 13:05, Waldhoff, Rodney wrote: I'm -1 until someone can clarify how/why this is different from the Jakarta Subprojects section of the home page. Why, perhaps it needs expansion! I look forward to reading it *duck* -Andy documentation lover O. Why not just add status information to that listing, if that's where the value-add is? How many places do we expect developers to update/document the status of their projects? -Original Message- From: acoliver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 11:16 AM To: [EMAIL PROTECTED] Subject: Re: Re: Jakarta Overview +1 - I'd like to see the detractors patch it as they see fit. On Tue, 19 Mar 2002 08:56:31 -0800 Daniel Rall [EMAIL PROTECTED] wrote. Ted Husted [EMAIL PROTECTED] writes: http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. I would be in favor of having the overview linked off of the About Jakarta section of the left nav. Index: project.xml === RCS file: /home/cvs/jakarta-site2/xdocs/stylesheets/project.xml,v retrieving revision 1.28 diff -u -u -r1.28 project.xml --- project.xml 17 Mar 2002 11:20:42 - 1.28 project.xml 19 Mar 2002 16:55:55 - @@ -17,6 17,7 @@ menu name=About Jakarta item name=Welcome href=/index.html/ item name=News Status href=/site/news.html/ item name=Overview href=/site/overview.html/ item name=Our Mission href=/site/mission.html/ item name=Our FAQs href=/site/faqs.html/ item name=Reference Library href=/site/library.html/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
first, good effort. Thanks. I am not deeply familiar with many of the Jakarta projects (in particular, I can't quite fathom the full extend of some of the frameworks, such as Avalon or Turbine, at this time), but in the spirit of 'release-early/release-often' I would like to make the information I have compiled so far available to the community. subsection name=Avalon !-- purported benefits of Avalon are hard to find out! -- the same as for any framework, mostly. where it says reusable components, best-of-practice pattern enforcements, etc, you'll find commercial companies talking about how it redefines the way you work, allows faster time-to-market, keep your programmers happy, etc etc. When .Net was first announced, did you have any idea what it was about? libFramework/b !-- No overview or list of features and functionalities -- pThe Avalon framework consists of interfaces that define relationships between commonly used application components, best-of-practice pattern enforcements, and several lightweight convenience implementations of the generic components./p i.e. the main feature is that it does some thinking work for you. It is easy to write bad software using Java. It becomes somewhat more difficult if you use Avalon. So, avalon framework itself has no simple real-life functionality (ie HTTP server). libPhoenix/b pMinimal Application Server (manages classloader, security and logging needs)/p pPurpose somewhat unlear, possibly still starting out./p phoenix is not an application server in the normal sense. Its a micro-kernel, which is something different. ul libDocumentation:nbsp;/bVery sketchy/li While this is true, I would appreciate it not to list something like this on the front page. It encourages people not even to look into the available docs, so to speak. libDocumentation:nbsp;/bExtensive: Several Overview documents, HowTos, Javadoc. Apparently no worked Hello world example./li It doesn't make sense to have turbine say hello world when it includes Velocity, which is there to talk to the world. In short, some projects on jakarta are not easy to capture in 'marketing' terms, because they have a possibly very wide scope. I don't think we should even attempt to do so for projects still in alpha (ie phoenix). regards, - Leo Simons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Waldhoff, Rodney [EMAIL PROTECTED] writes: I'm -1 until someone can clarify how/why this is different from the Jakarta Subprojects section of the home page. One difference that I've noticed is that overview.xml is a more complete and comprehensive list of projects, where as the Subprojects section is missing quite a few -- I speculate that it may only be listing first-tier Jakarta projects, rather than their sub-projects as well (which are often times quite different and worth listing somewhere other than the home page of the first-tier projects). Why not just add status information to that listing, if that's where the value-add is? How many places do we expect developers to update/document the status of their projects? I'm no such a fan of the status information myself, but really like the comprehensive listing. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
