Re: [RANT] The Cocoon website: move on, nothing is happening here
Arje Cahn wrote:
I just have to share my frustrations.
snip/
Arje,
I share your frustrations and agree to many of the points you raised. It's not
that nothing happens - Helma and I made good progress at the GT. See
http://cocoon.zones.apache.org/daisy/cdocs/1201.html and
http://people.apache.org/~reinhard/cocoon-docs/1213_1_1.html. We have a working
CMS and an export mechanism based on Maven so that we can meet all requirements
imposed by ASF infra. Read
http://marc.theaimsgroup.com/?t=11589400221r=1w=2 to find out more about
the details.
In short, *the tools are working*. What we need is help when it comes to edit
and restructure our docs. If you want to join us, just go to
http://cocoon.zones.apache.org/daisy/, look for the part of our documentation
that you want to work on and just do it. BTW, the upcoming main site can be
found at http://cocoon.zones.apache.org/daisy/cdocs-site-main/g1/1213.html. If
you don't have the necessary rights, just let us (me) know.
I agree to all your comments about the up-to-dateness. Yes, we need to be more
dynamic, present news and links to our blogs. I will setup a new homepage in and
news page in Daisy ASAP so you and others get an idea.
We probably need some help when it comes to setup an aggregated Cocoon weblog as
it will be difficult for us to run this kind of stuff. Maybe we can setup the
process on our zone and rsync it from somewhere else. Any ideas?
Finally, yes we were talking about some new fancy design for our website but
that's just a piece of the big picture. Unfortunatly this picture consists of
many pieces and we need help at all ends.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: [RANT] The Cocoon website: move on, nothing is happening here
On Wednesday 18 October 2006 03:51, Steven Noels wrote: What those Belgian guys however (in)frequently murmured amongst themselves was: why the stupid fixation with SVN as a required content repository for official ASF documentation sites? Why can't cocoon.apache.org simply be a proxy for http://cocoon.zones.apache.org/daisy/documentation/ ? I think it is related to the principles of primary resources; - mailing lists - subversion - ? which infrastructure works hard to make sure are operational, backed-up, fail-over, disaster planning et al. Wiki and other stuff is not considered primary, and doesn't enjoy the attention of the infrastructure folks. Cheers Niclas
Re: Cocoon on projects.apache.org
On 10/17/06, Sylvain Wallez [EMAIL PROTECTED] wrote: ...So, should we restrict ourselves to a single category (rather limiting for Cocoon), or fix project.a.o to allow multiple categories?.. Fixing projects.a.o would be better, IIRC this is David Reid's work? I haven't found a contact address there. -Bertrand
Re: Cocoon on projects.apache.org
Hi, On 18 Oct 2006, at 09:23, Bertrand Delacretaz wrote: On 10/17/06, Sylvain Wallez [EMAIL PROTECTED] wrote: ...So, should we restrict ourselves to a single category (rather limiting for Cocoon), or fix project.a.o to allow multiple categories?.. Fixing projects.a.o would be better, IIRC this is David Reid's work? I haven't found a contact address there. Yes, David is behind it - he did a talk about it at ApacheCon US. IIRC Leo Simons may be driving it toward being an official project, but meanwhile I guess David is our guy. Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: Cocoon on projects.apache.org
Bertrand Delacretaz wrote: Sylvain Wallez wrote: ...So, should we restrict ourselves to a single category (rather limiting for Cocoon), or fix project.a.o to allow multiple categories?.. Fixing projects.a.o would be better, IIRC this is David Reid's work? I haven't found a contact address there. It does allow multiple categories. See http://projects.apache.org/projects/cocoon.html At one time these multiple categories were functioning properly and all were listed at http://projects.apache.org/indexes/category.html etc. Something has changed recently with his site generation and broken it. The site-dev AT a.o list is where it happens. http://www.apache.org/dev/infra-mail.html -David
RE: [RANT] The Cocoon website: move on, nothing is happening here
Steven said: What those Belgian guys however (in)frequently murmured amongst themselves was: why the stupid fixation with SVN as a required content repository for official ASF documentation sites? I can see the benefits of having all content (replicated) in SVN. But in principle, yes, there's too much 'stupid fixation' going on anyway. You should have been there when I decided not to wait for Java hosting @ ASF, simply rented a server, and installed JSPWiki under the cocoondev.org domain. Well, as you know, I was kind of there. And I think you did Cocoon a really big favour by doing it in that way. In your stubbornness, you have definitely leveraged the Cocoon community in many ways. I don't want JSPWiki back, either, but there are structural errors in the way the Wiki is organized nowadays. I would like to see some sort of integration between the Wiki and the 'official' website in such a way that they have an accelerating effect on each other. There's (almost BY DEFINITION) too much redundancy and conflicting information in both sites. They've been pulling eachother down for a long time. A differentiation between an official Apache website and a community driven website sounds so paradoxal to me. The 'community driven websites' have helped Cocoon move forward, the 'official' one is the one currently killing it. While I agree with your sentiments, I can only say that things have grown organically into what they are now. It's what the community wanted. Don't get me wrong - I'm not blaming anyone. The community has changed a lot over time, and Cocoon has grown mature. With that, it's clear that some of the original pioneering work is gone, and the focus might better shift to end-users instead of (Apache) developers that instinctively know their way around in the ASF information clutter. A few weeks ago, I was talking with Jeff Turner, with him suggesting that it would be better to suggest Daisy instead of Confluence for incubating ASF projects who are looking for a website management tool. Of course, you would understand that I would not take any position regarding Daisy. :) But whatever it is we need to get things going again, I'm all for it. The Cocoon community has always been really strong, but it's too much centralized on the mailinglists right now. The outside visibility is therefor completely nonexistant. Maybe the discussion is (again?) not about what's going wrong with the Cocoon community, but what's going wrong with what the ASF allows us to do. I don't know about the real bounderies there, so please tell me. - Can we have a Wiki integrated with the Cocoon website? - As such, can we have both in 1 content repository so we can effectively move interesting Wiki pages into the documentation? - Can we display a feed of current activitiy on the mailinglists? Can we display the 10 latest messages on the user/dev list right on the homepage? - Can we have a forum? (Ok, I guess we can't, but maybe there's a way to display the mailinglists in a forum-style way? It's just the visibility I'm talking about) - Can we add blogposts (from committers) to the Cocoon website? - Are we tied to any ASF rules for structure or design of our website? - Can we have 'subsites' hosted below the official Cocoon website? Aka, the CocoonGT website? Just some thoughts.. Arjé
Error on widget state documentation
Hi, I think I just found a small error on the widget state documentation on the Cocoon site: http://cocoon.apache.org/2.1/userdocs/widgetconcepts/widgetstates.html It's contents seems to be duplicated. In Daisy however, things look fine (by following the link at the bottom of the page: http://cocoon.zones.apache.org/daisy/legacydocs/733). Bart.
Re: [RANT] The Cocoon website: move on, nothing is happening here
Thanks Arje for starting this thread. And, despite your (justified) negative view on the current state of our website, big thanks to those who have been investing lots of time trying to make it happen over the years. Few of us have been really paying attention, it's easy to make a lot of noise now about our site sucking now (nothing against you Arje, I'm speaking in general terms). Our (collective) ambitions have often not been matched by our (individual) efforts. The history of the http://wiki.apache.org/cocoon/CocoonWebsiteUpdate page says a lot about this, and Steven's efforts in getting a decent wiki going, at the time, are to be noticed as well - big thanks. If we can think in small steps instead of throwing out all our tools as we tend to do in such situations, I'd suggest simply finding a way to make the http://cocoon.apache.org/ homepage more alive, by making it easy and quick for us to update it indepentendly of the other pages. Heck, editing a static page might be good enough, or running an XSLT transform locally to generate it from a blog-like news XML file in order to have an RSS news feed as well. Add to this a link to a blog aggregator (planetcocoon.org?) for cocoon-related posts by members of this community, and we'd have much more life on our website already, with little effort. -Bertrand
RE: [RANT] The Cocoon website: move on, nothing is happening here
Bertrand said: Thanks Arje for starting this thread. :-) And, despite your (justified) negative view on the current state of our website, big thanks to those who have been investing lots of time trying to make it happen over the years. Few of us have been really paying attention, it's easy to make a lot of noise now about our site sucking now (nothing against you Arje, I'm speaking in general terms). I totally agree with you. It sure is easy to say the website sucks :) I'd suggest simply finding a way to make the http://cocoon.apache.org/ homepage more alive Yes! Add to this a link to a blog aggregator (planetcocoon.org?) for cocoon-related posts by members of this community, and we'd have much more life on our website already, with little effort. Absolutely! But - and I'm gonna be a real pain in the butt about this - it should *not* be at planetcocoon.org. It should be at cocoon.apache.org. We need to give visitors something to look at, at the place where they start looking (see my first email). This is NOT AGAIN another website, it should be the Cocoon main website. Arje
Re: [RANT] The Cocoon website: move on, nothing is happening here
On 10/18/06, Arje Cahn [EMAIL PROTECTED] wrote: ...This is NOT AGAIN another website, it should be the Cocoon main website... Cool - if you can be enough of a pain to make this happen, I'll put you on my I-owe-you-a-beer list ;-) -Bertrand
Re: [RANT] The Cocoon website: move on, nothing is happening here
Bertrand Delacretaz said the following on 18/10/06 13:56: Thanks Arje for starting this thread. +1 Guys, since the documentation is my main focus, I want to chime in here. Re the redesign of the website: I haven't discussed this much with Reinhard, but my intention was a new revamped website once 2.2 is released. Revamped does not only include new shiny looks, but IMO also a restructuring of the info and a more lively homepage. When Daisy was put up on the zones as our main documentation repository, I had already planned for a restructuring, but arguments that the URL space had to be preserved prevented this. So I decided to comply and wait for 2.2. Re the information is all over the place: I fully agree and since I became committer I've tried several times to get the role of at least the website and the wiki clear. I won't bother now to find all these threads. The discussions either turned into yet another tooling proposal or faded out when other more code-related topics appeared. My own lack of time and the fact that I wasn't able to motivate/scare/bribe/kick the rest of the community into writing documentation hasn't added much to the process. I do have to say that this didn't boost my motivation either. I know that open source projects thrive on voluntary work and that we should be grateful for all the work that's contributed, but I cannot dismiss the feeling that documentation is generally considered to be done by someone else, while we all curse the moment when we turn to the documentation and find it inadequate. I know that the current process of updating the cocoon.apache.org website is cumbersome, but still it's a whole lot better than the previous process. I really don't care if it takes one step or twenty, if in the end all I need to do is set a timer that reminds me to provide my username/password to start the update process every X days, I'd be glad to do that. However, that doesn't make sense when nobody bothers to write. Moving over the legacy documentation at the time was done with reuse in mind. However, that means that people, knowledgable of the topic, have to go over it and verify it. No such actions, give or take a few, have been done. Several people have written how documentation should be written and when I read the recent version I bitterly remembered reading almost identical stuff written by Dianne Shannon way back then. However, only few actual pages have been written. I've spent both Hackathon days implementing the documentation infrastructure Reinhard has designed. Although I see some advantages in his setup, I didn't feel any pride over it. I merely contributed to more metadata, no actual documentation. This is where I think the main problem lies: - discussions on documentation on the mailinglists swerve off topic and into tooling and code before the fifth reply is in. - documentation is regarded as something evil/boring/without merits or whatever I agree with Bertrand that we should take small steps, but let's define the steps first and agree on this, put them up somewhere and stick to them. Let's not wait for the miracle of self-describing documentation, or the overall genius (me ;-) ) that can write it overnight. Let's simply agree that it's part of the job and should be done as well. For all the roadmaps that have been written, discussed and discarded, let us now finally write one for the documentation and stick to it. Use some of your code hacking time to write documentation. Don't wait for others to do, be the first to write. If you think documentation has to be perfect in the first instance, you're wrong. The only thing necessary is the correctness of the information. If you write it down in notes, full of spelling errors and grammar clashes, nobody cares and I'd be glad to go over it and polish it up. My proposal is: I start several new threads regarding the documentation on this mailinglist. Each thread contains a single topic, e.g. position of wiki vs Daisy, documentation structure, documentation roadmap. We can discuss the various ideas but WE REMAIN ON TOPIC or start a new thread. The end result should be one or more documents in Daisy that express our consensus on what the documentation should look like and how each community member can contribute and which rules we have to live by (e.g. no code release unless there is sufficient documentation). And once we agree (whether through voting or through general consensus I don't care), we stick to it and follow it through. Sorry if this sounds a bit emotional, but that's how I feel. Bye, Helma
Re: [RANT] The Cocoon website: move on, nothing is happening here
hepabolu wrote: I know that the current process of updating the cocoon.apache.org website is cumbersome, but still it's a whole lot better than the previous process. I really don't care if it takes one step or twenty, if in the end all I need to do is set a timer that reminds me to provide my username/password to start the update process every X days, I'd be glad to do that. However, that doesn't make sense when nobody bothers to write. And that, as most of us know, is the real problem. It really makes no difference how easy/hard documentation and publishing is. It just doesn't happen. For those new to this kind of discussion just check the archives - the solution proposed is always tools (and I've done it myself in the past). The new tools arrive and still there is no documentation. Ross
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (88 issues) Subscriber: cocoon Key Summary COCOON-1933 [Patch] Automatic loading of flow scripts in flow/ must not load directories http://issues.apache.org/jira/browse/COCOON-1933 COCOON-1932 [PATCH] correct styling of disabled suggestion lists http://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 http://issues.apache.org/jira/browse/COCOON-1929 COCOON-1921 A bug in org.apache.cocoon.classloader.DefaultClassLoader http://issues.apache.org/jira/browse/COCOON-1921 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded http://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList http://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList http://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice http://issues.apache.org/jira/browse/COCOON-1899 COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin http://issues.apache.org/jira/browse/COCOON-1898 COCOON-1893 XML-Binding: Problem creating a new element http://issues.apache.org/jira/browse/COCOON-1893 COCOON-1890 Provide a tool to update artifact versions within multiple POMs http://issues.apache.org/jira/browse/COCOON-1890 COCOON-1879 Make fd:field whitespace trimming behavior configurable http://issues.apache.org/jira/browse/COCOON-1879 COCOON-1877 [PATCH] Pageable Repeater http://issues.apache.org/jira/browse/COCOON-1877 COCOON-1870 Lucene block does not store attributes when instructed so http://issues.apache.org/jira/browse/COCOON-1870 COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the rigth time with IE http://issues.apache.org/jira/browse/COCOON-1846 COCOON-1843 LDAPTransformer: add-entry tag doesn't work http://issues.apache.org/jira/browse/COCOON-1843 COCOON-1842 LDAPTransformer: ClassCastException with Binary fields http://issues.apache.org/jira/browse/COCOON-1842 COCOON-1838 Always use 3-digit version number http://issues.apache.org/jira/browse/COCOON-1838 COCOON-1811 [PATCH] Flow Script: Allow dynamic loading of JavaScript objects even when scope is locked http://issues.apache.org/jira/browse/COCOON-1811 COCOON-1810 [PATCH] JMSEventMessageListener does not work http://issues.apache.org/jira/browse/COCOON-1810 COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding http://issues.apache.org/jira/browse/COCOON-1794 COCOON-1776 [PATCH]Reload Bookmarks on bookmark file validity http://issues.apache.org/jira/browse/COCOON-1776 COCOON-1738 double-listbox problem in repeaters http://issues.apache.org/jira/browse/COCOON-1738 COCOON-1726 Implementation of Source that supports conditional GETs http://issues.apache.org/jira/browse/COCOON-1726 COCOON-1717 Use custom cache keys for caching uri coplets using input modules. http://issues.apache.org/jira/browse/COCOON-1717 COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text orientation, color code fix, prefered unit for margins and measure unit converter http://issues.apache.org/jira/browse/COCOON-1703 COCOON-1697 Allow request parameters to be used in for (var k in h) kind of Javascript Loops http://issues.apache.org/jira/browse/COCOON-1697 COCOON-1686 [PATCH] COCOON-1671 Form not binding when prefix in binding definition is unequal to that in the instance data for the same namespace. http://issues.apache.org/jira/browse/COCOON-1686 COCOON-1648 Add support for ISO8601 in I18nTransformer and Forms http://issues.apache.org/jira/browse/COCOON-1648 COCOON-1622 [PATCH] SendMailTransformer and HTML body http://issues.apache.org/jira/browse/COCOON-1622 COCOON-1618 [PATCH] SoapGenerator/Serializer for Axis Block http://issues.apache.org/jira/browse/COCOON-1618 COCOON-1611 [PATCH] Add additonal constructor to FormInstance.java to be able to pass a locale http://issues.apache.org/jira/browse/COCOON-1611 COCOON-1603 [PATCH] handling of alternatives in MailTransformer http://issues.apache.org/jira/browse/COCOON-1603 COCOON-1573 Improvement SetAttributeJXPathBinding and Contribution SetNodeValueJXPathBinding http://issues.apache.org/jira/browse/COCOON-1573 COCOON-1557 [PATCH] Change access to AbstractContinuable.getContext to protected http://issues.apache.org/jira/browse/COCOON-1557 COCOON-1556 [PATCH] Add a JXPathConvertor for conversion betwean beans and Strings
Re: [RANT] The Cocoon website: move on, nothing is happening here
Arje Cahn skrev: ... The discussion about a new design for our website is great, but I feel there are much bigger mistakes that we have to get straightened out before the shinyness of our website is of any importance. We need to decide where we put what, as it's currently spread all over the place: Cocoon website, mailinglists, the Wiki, blogs, zones.apache, Daisy documentation, etc etc... Can agree that design isn't the highest priority. Neither the less it is important and it is the first thing that meats the eyes of a newcomer. The current design is something that we (thanks to the popularity of Forrest) shares with hundreds of sites. So everybody have seen it before. As we would like to think of Cocoon as something unique we shouldn't look like everybody else. So if we have people in the community who have the talent do do something about it, we should wholeheartedly support such efforts. So here's my list of things that TOTALLY SUCK about the Cocoon website :-) - Someone has to maintain the Cocoon News page. There are now 4 entries on the page, spanning a total 2 years of news. That totally sucks! For a newcomer, this is not a good sign. It would really help, if we got someone to add 1 news entry every month, with 3 lines minimum. We've recently added a bunch of committers to the project, which is perfect to show that we're not DEAD. Let's put it on there! Agree, we have plenty of activity in our community, so a couple of news items per month would be a much better reflection of our reality. So how do we achieve this? First I think we need some common idea about what is a news item. Some suggestions would be: * New releases (with separate releases of the blocks there should be plenty of things to report) * Cocoon GT and ApacheCon and other conferences with Cocoon presentations * Links to articles about or mentioning Cocoon and any other media coverage * New products and (larger) sites using Cocoon * New committers and ASF members with short presentations (Cocoon is a strong and active community and that should be visible) * New bloggs with Cocoon focus * Important new features or developments * Important discussions on the mail lists More ideas? Second we need some (simple) way to suggest news. I think we should suggest possible news items at the dev-list by having a special headers prefix like [news]. Third, as the website is our official voice, we need some kind of community oversight. I think lazy consensus should be enough. If no one have protested in maybe three days, we should add the news item to the news page. Of course if someone with marketing skills would like volunteer and take a larger responsibility for creating and editing the news contents that would great. - NEWS should be on the HOMEPAGE, not 2 clicks away from the homepage. I mean, look at *any* commercial website and see how many clicks you need to get to the news and marketing yadayada. Agree completely. Let's imagine a first time visitor to our site. The reason that she got to our site is probably that she has heard or read about Cocoon and follow a link from another site or a search machine to learn more. What will create most motivation for actually learning more about Cocoon, an fairly abstract description about what Cocoon is or lots of news items showing that this is the place where the action is ;) And the returning visitor already know what Cocoon is, so for her it is much more interesting to learn what is new and what happens. It must of course be easy to find information about what Cocoon is, but it shouldn't be the main content of the home page. On the homepage it should be enough with one or two sentences about what it is. Take a look at Spring e.g. own visual design and it starts with: Welcome to the home of the Spring Framework. As the leading full-stack Java/J2EE application framework, Spring delivers significant benefits for many projects, reducing development effort and costs while improving test coverage and quality. And then they continue with lots of news. That shows self confidence! So why are we explain how it is: Welcome to the home of the Cocoon Framework. As the leading XML/Java web application framework, Cocoon delivers significant benefits for many projects, reducing development effort and costs while improving test coverage and quality. ;) ... - Documentation (sorry, Helma). So, it was Stefano's dream to once have a Cocoon CMS and run the Cocoon website with it. I don't think part of this dream was to tuck it away on a hidden location so it will be forgotten forever. How embarissing it is to see Helma working at the GT practically alone on all our docs. This has everything to do with the total invisibility of the documentation website. Let's bring it out into the spotlights. Let's give every committer a login, or better yet, get Daisy to talk to the ASF's authentication server (free advice Belgian
Re: [RANT] The Cocoon website: move on, nothing is happening here
Daniel Fagerstrom wrote: we have plenty of activity in our community, so a couple of news items per month would be a much better reflection of our reality. So how do we achieve this? Some options (which don't require new tools): Daisy can be used to create blog like pages that can be automatically brought together into a news page. I agree that it should be the home page, but Daisy would not limit the info to just this page. Perhaps 3 items on the home page, and a larger news only page. Note that Daisy can also be made to create RSS feeds, but that's a next step. Alternatively, have the site generation pull content from peoples existing blogs. Forrest has a plugin for this (although it is pretty basic), I'm sure Maven can be made to do it. The problem with this approach is that there is no control over the content that is published. Of course there are lots of other ways, but they involve new tools so I'm steering away form those. First I think we need some common idea about what is a news item. Some suggestions would be: All your suggestions look just fine, I'm sure having an exhaustive list is impossible, but your list is a great starting point. I'm more concerned about *who* will write these items and who will publish the site frequently. It really is a case of providing a login and password to a publishing tool after it is configured. Which publishing tool to use? I don't care. Forrest does it well (but it does need a new skin, there is a partially complete skin that Helma and I put together some time ago, but I have not had the time to finish it off yet. Second we need some (simple) way to suggest news. I think we should suggest possible news items at the dev-list by having a special headers prefix like [news]. I'd suggest just letting (self-registered) people add a news item to Daisy. Committers items will be published automatically, others will require publication by a committer - in daisy this is just a click of a link once logged in. Posting to the list is just a step too many in my view. Why not put it straight in Daisy where it can be edited and published quickly and easily. Don't forget Daisy edits are already sent to the docs list. Third, as the website is our official voice, we need some kind of community oversight. I think lazy consensus should be enough. If no one have protested in maybe three days, we should add the news item to the news page. Of course if someone with marketing skills would like volunteer and take a larger responsibility for creating and editing the news contents that would great. Sure, this all works fine with direct entry into Daisy rather then on the list (where everyone and their dog will chip in but only one or two will actually do anything). Daisy can be configured to only publish items that were written x days ago, thus automatically allowing for lazy consensus. --- I support the above as a small step, I think it may encourage more people into using Daisy a little. Ross
