You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/02/16 23:05:59 UTC
Cocoon Project Report
As requested by the chairman, I send in a report of the activities
performed by the Cocoon Project so far.
- o -
The Cocoon Project is slowly starting up.
We are in the progress of establishing the voting rules (taken from
Avalon) so that we can start the PMC.
The PMC mail list has not been setup yet. I wanted to have the voting
rules resolved in public (means cocoon-dev) before asking
instrastructure@ to setup the pmc@cocoon.apache.org mail list.
Our policy will be to reduce traffic on pme@cocoon.apache.org to only
those discussions that *require* privacy. Everything else will be done
in public.
The first PMC action will be to resolve the 'recursive bylaws' issue.
The second PMC action will be to establish a policy for the potential
use of the Cocoon name on commercial interests or cocoon-related non-ASF
web sites.
Infrastructure-wise, we are slowly moving away from our current
xml.apache.org location into cocoon.apache.org but we want to plan ahead
the movement to reduce user damage (broken links, mail archives and
such). Mirroring is also working even if not all links in our docs has
been updated (we plan on doing that after the move)
Pier Fumagalli has been voted back as a Cocoon committer (after his
renewed intention to work on cocoon and several patches submitted) and
is helping us a lot with infrastructure issues directly, reducing the
work on infrastructure@ directly.
At the same time, we would like to work with the other new top-level
project to synchronize the process of writing such PMC-oriented docs and
such. I'm peronally keeping an eye on infrastructure@ community@ and
general@incubator for those things and cocoon and avalon are already
sharing pieces of PMC-related work.
We are also planning to start using Forrest to build our own
documentation, even if this will make it a circular dependency (cocoon
depends on forrest and forrest depends on cocoon). But this is something
the cocoon documentation team will decide with the forrest developers
(most of which are also cocoon developers).
As far as community information, the cocoon communities appear healthy,
active and friendly. The high-rate of users becoming committers and
committers coming out of emerius status indicates a sane darwinistic
environment, well matched by the fact that only individuals or
small-sized companies perform most of Cocoon development and maintance,
allowing the community to be in total control. Frinction rate and
ego-oriented problems are, as usual, close to zero and I see no signs of
problems ahead.
- o -
As a special note, I would like to mention how the introduction of the
Cocoon wiki (hosted personally by Steven Noels' web site
www.cocoondev.org) has been seen by the user community as a great tool
and has generated very high-quality and useful documentation. The cocoon
wiki was also patched to sends diffs to the cocoon-docs@xml.apache.org
mail list (the documentation team), providing ownership and oversight.
This is seen as a very useful tool by the documentation team.
This has let us to believe that our current xml-driven documentation
system must be improved to match the editing simplicity of a wiki-based
solution, but without the unstructured-text problems of wiki content.
My personal vision is that Forrest should be dealing with those issues
and Cocoon help them with the technology they need, but that a better
documentation editing infrastructure is needed in order to allow a more
general audience to help us with that task.
Stefano Mazzocchi - V.P. Apache Cocoon
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Project Report
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> As a special note, I would like to mention how the introduction of the
> Cocoon wiki (hosted personally by Steven Noels' web site
> www.cocoondev.org) has been seen by the user community as a great tool
> and has generated very high-quality and useful documentation. The cocoon
> wiki was also patched to sends diffs to the cocoon-docs@xml.apache.org
> mail list (the documentation team), providing ownership and oversight.
> This is seen as a very useful tool by the documentation team.
Thanks. As a starter, I was planning to run Cocoon and JSPWiki
side-by-side using Stephan Michel's enhanced cwiki grammar for Chaperon
as micro-outlined at the bottom of
http://wiki.cocoondev.org/Wiki.jsp?page=Wishlist
That way, we can already easily extract xdoc-markuped documents out of
the Wiki. Help and suggestions are welcomed, since I have some other
cocoondev.org things in the backlog.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> Of course, slide + Wyona + etc is the final goal
Please let's not jump to conclusions ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> Of course, slide + Wyona + etc is the final goal
Please let's not jump to conclusions ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Diana Shannon <sh...@apache.org>.
On Wednesday, February 19, 2003, at 12:05 PM, Nicola Ken Barozzi wrote:
> I have introduced ihtml and cwiki for the sole reason to make doc
> editing much easier. Imagine that our doccers use Webdav on Subversion
> to commit doc changes, in html or wiki format. Plain easy, and
> subversion gives us revisions.
I need time to check this approach out in greater detail over the
weekend. I'll report back with impressions.
Thanks to everyone for the great input on this thread!
Diana
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 19/02/2003 15.49:
...
> So there's a half-formed plan over in Forrest-land to migrate to XHTML 2
> as an intermediate format, and make it one of the frontend formats too:
>
> http://marc.theaimsgroup.com/?l=forrest-dev&m=104351979527689&w=2
Then why not use html (ihtml), there are loads of editors.
I have introduced ihtml and cwiki for the sole reason to make doc
editing much easier. Imagine that our doccers use Webdav on Subversion
to commit doc changes, in html or wiki format. Plain easy, and
subversion gives us revisions.
Add to that SSL so we don't need to give unix accounts to everyone that
collaborates on our CVS, and that the wiki files can be edited by anyone
using subwiki, and you have a *usable* the poor man's CMS.
Of course, slide + Wyona + etc is the final goal, but in the meantime
this could be a step in that direction.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote, On 19/02/2003 15.49:
...
> So there's a half-formed plan over in Forrest-land to migrate to XHTML 2
> as an intermediate format, and make it one of the frontend formats too:
>
> http://marc.theaimsgroup.com/?l=forrest-dev&m=104351979527689&w=2
Then why not use html (ihtml), there are loads of editors.
I have introduced ihtml and cwiki for the sole reason to make doc
editing much easier. Imagine that our doccers use Webdav on Subversion
to commit doc changes, in html or wiki format. Plain easy, and
subversion gives us revisions.
Add to that SSL so we don't need to give unix accounts to everyone that
collaborates on our CVS, and that the wiki files can be edited by anyone
using subwiki, and you have a *usable* the poor man's CMS.
Of course, slide + Wyona + etc is the final goal, but in the meantime
this could be a step in that direction.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 19, 2003 at 01:39:56PM +0000, Pier Fumagalli wrote:
> "Jeff Turner" <je...@apache.org> wrote:
>
> > So I agree with Diana about moving all docs to the Wiki. It seems the
> > best long-term solution, avoiding all the problems that a dual wiki/xdoc
> > system would cause.
>
> I disagree on that. IMO the "Wiki" syntax doesn't have the capability to
> contextualize the information contained in the document (how can we tell
> that a "screenshot" is different from a "configuration file snippet?" - in
> "Wiki" it's all a big <PRE>...</PRE> whatever).
In doc-v11 we'd have to abuse <code> to do that. The XML format is so
limited that this kind of abuse becomes necessary. We could add
<screenshot> and <configuration> tags, but where does the tag-adding
process end?
Its sad, but right now, CSS-happy XHTML is often more semantically rich
than doc-v11 XML documentation. We could use:
<div style="configuration">
</div>
Which is a DTD-friendly equivalent of <configuration>.
So there's a half-formed plan over in Forrest-land to migrate to XHTML 2
as an intermediate format, and make it one of the frontend formats too:
http://marc.theaimsgroup.com/?l=forrest-dev&m=104351979527689&w=2
--Jeff
> Otherwise, what's the point of using XML anyway. I could use FrontPage and
> web folders and get done with it...
>
> Pier
>
Re: xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 19, 2003 at 01:39:56PM +0000, Pier Fumagalli wrote:
> "Jeff Turner" <je...@apache.org> wrote:
>
> > So I agree with Diana about moving all docs to the Wiki. It seems the
> > best long-term solution, avoiding all the problems that a dual wiki/xdoc
> > system would cause.
>
> I disagree on that. IMO the "Wiki" syntax doesn't have the capability to
> contextualize the information contained in the document (how can we tell
> that a "screenshot" is different from a "configuration file snippet?" - in
> "Wiki" it's all a big <PRE>...</PRE> whatever).
In doc-v11 we'd have to abuse <code> to do that. The XML format is so
limited that this kind of abuse becomes necessary. We could add
<screenshot> and <configuration> tags, but where does the tag-adding
process end?
Its sad, but right now, CSS-happy XHTML is often more semantically rich
than doc-v11 XML documentation. We could use:
<div style="configuration">
</div>
Which is a DTD-friendly equivalent of <configuration>.
So there's a half-formed plan over in Forrest-land to migrate to XHTML 2
as an intermediate format, and make it one of the frontend formats too:
http://marc.theaimsgroup.com/?l=forrest-dev&m=104351979527689&w=2
--Jeff
> Otherwise, what's the point of using XML anyway. I could use FrontPage and
> web folders and get done with it...
>
> Pier
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by SAXESS - Hussayn Dabbous <da...@saxess.com>.
you may look at the CocoonCompetenceCenter for Metadata issues.
There we alkready started doing something into this direction.
Maybe this helps as contribution:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=104369287706014&w=2
http://wiki.cocoondev.org/Wiki.jsp?page=BeginnerPageTemplate
It would be great, if the Wiki could support the BeginnerPageTemplate
or something equivalent and just add it into a freshly created
Wiki-Page ?
Then the formal requirements could be fullfilled with less pain.
Or the other idea is to add a module to the Wiki, that handles
metadata (an idea which Bertrand/Steve brought in some time ago)
regards, Hussayn
Jeff Turner wrote:
> On Wed, Feb 19, 2003 at 09:01:26AM +0100, Bertrand Delacretaz wrote:
>
>>Le Mercredi, 19 fév 2003, à 08:45 Europe/Zurich, Jeff Turner a écrit :
>>
>>
>>>...So I agree with Diana about moving all docs to the Wiki. It seems
>>>the
>>>best long-term solution, avoiding all the problems that a dual
>>>wiki/xdoc
>>>system would cause.
>>
>>I tend to agree but OTOH there must be some way for users to find out
>>about the reliability of a document.
>>
>>Currently, I think the xdocs are viewed are "official" whereas the wiki
>>is more like "melting pot" - the difference is easy, even though the
>>good quality of many wiki docs makes it more blurred in practice.
>>
>>So I think, if in the future all docs are done on a wiki, some form of
>>metadata/review system is required so that the state and validity of a
>>particular document is clearly visible.
>
>
> Agreed. Perhaps just a section at the top of each page for "Reviewed by
> <author> at <date>" declarations?
>
> Another bit of important metadata is the Cocoon version (2.0.x or 2.1)
> that the doc applies to.
>
> --Jeff
>
>
>>-Bertrand
>>
>>
>
--
Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax: +49-221-56011-20
E-Mail: dabbous@saxess.com
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by SAXESS - Hussayn Dabbous <da...@saxess.com>.
Just another proposal:
If the docs really move toward a Wiki, i would highly appreciate,
if we set up authentification for the editors. This may be
contrary to the original Wiki idea, but i personally would feel
better if i know all editors by email-adress ;-)
regards, hussayn
Bertrand Delacretaz wrote:
>> ...Agreed. Perhaps just a section at the top of each page for
>> "Reviewed by
>> <author> at <date>" declarations?
>
>
> Something like that - see Hussayn's message and references, this was
> discussed recently.
>
>> Another bit of important metadata is the Cocoon version (2.0.x or 2.1)
>> that the doc applies to.
>
>
> Yes, and as the Wiki does versioning, one can even imagine being able to
> "go back in time" online in the docs to find out about info that was
> valid for a given version...
>
> -Bertrand
>
--
Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax: +49-221-56011-20
E-Mail: dabbous@saxess.com
Re: xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
> ...Agreed. Perhaps just a section at the top of each page for
> "Reviewed by
> <author> at <date>" declarations?
Something like that - see Hussayn's message and references, this was
discussed recently.
> Another bit of important metadata is the Cocoon version (2.0.x or 2.1)
> that the doc applies to.
Yes, and as the Wiki does versioning, one can even imagine being able
to "go back in time" online in the docs to find out about info that was
valid for a given version...
-Bertrand
Re: xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 19, 2003 at 09:01:26AM +0100, Bertrand Delacretaz wrote:
> Le Mercredi, 19 fév 2003, à 08:45 Europe/Zurich, Jeff Turner a écrit :
>
> >...So I agree with Diana about moving all docs to the Wiki. It seems
> >the
> >best long-term solution, avoiding all the problems that a dual
> >wiki/xdoc
> >system would cause.
>
> I tend to agree but OTOH there must be some way for users to find out
> about the reliability of a document.
>
> Currently, I think the xdocs are viewed are "official" whereas the wiki
> is more like "melting pot" - the difference is easy, even though the
> good quality of many wiki docs makes it more blurred in practice.
>
> So I think, if in the future all docs are done on a wiki, some form of
> metadata/review system is required so that the state and validity of a
> particular document is clearly visible.
Agreed. Perhaps just a section at the top of each page for "Reviewed by
<author> at <date>" declarations?
Another bit of important metadata is the Cocoon version (2.0.x or 2.1)
that the doc applies to.
--Jeff
> -Bertrand
>
>
Re: xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 19, 2003 at 09:02:42AM +0100, SAXESS - Hussayn Dabbous wrote:
> Hy;
Let's move this thread over to cocoon-docs..
--Jeff
...
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 19 fév 2003, à 10:14 Europe/Zurich, Jeff Turner a écrit :
> ...
> @cocoon-version 2.0.4 -> has URL '/wiki/2.0.4/CocoonCaching'.
> @cocoon-version 2.1' -> has URL '/wiki/2.1/CocoonCaching'.
The cool thing would be to couple "2.0.4" with a version management tag
a la CVS...
i.e. "2.0.4" would retrieve the version of the page that has been
marked valid for 2.0.4, but there would be only one CocoonCaching page.
-Bertrand
P.S.
LOUD VOICE OFFSTAGE TO MYSELF: now stop it! you're dreaming up stuff
again instead of actually working ;-)
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by Stephan Michels <st...@apache.org>.
On Wed, 19 Feb 2003, Jeff Turner wrote:
> On Wed, Feb 19, 2003 at 09:02:42AM +0100, SAXESS - Hussayn Dabbous wrote:
> > Hy;
> >
> > The mentioning of "Wiki" triggered my curiousity:
> >
> > If we move all docs to Wiki, then how can we maintain
> > different release versions of the docs ?
> >
> > Or will there be only one single document version, that
> > fits for all released cocoon versions ?
>
> Many docs will be applicable to both versions. Many will apply to only
> one version. Is anything beyond a page naming convention required to
> distinguish the two?
>
> > Or do you propose to connect Wiki with an underlying
> > document management system?
>
> Underlying what? :) Back in my day, ice-creams were 5c each, school was
> a 10 mile walk through blizzards, and filesystems were good enough for
> everyone.
>
> But yes, that is a good point. Being able to roll back files is probably
> essential for serious doc use. We could simply set up a logrotate script
> on the server to back up each day's content.
Perhaps the Slide block is an option. It's support versioning, metadata
etc. If you want, you can use a WebDAV server. There are more than one
possible stores, which can be used(File, JDBC, ...). I know that
Software AG formally known as Tamino used Slide.
Just a thought, Stephan Michels.
Re: xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 19, 2003 at 09:02:42AM +0100, SAXESS - Hussayn Dabbous wrote:
> Hy;
>
> The mentioning of "Wiki" triggered my curiousity:
>
> If we move all docs to Wiki, then how can we maintain
> different release versions of the docs ?
>
> Or will there be only one single document version, that
> fits for all released cocoon versions ?
Many docs will be applicable to both versions. Many will apply to only
one version. Is anything beyond a page naming convention required to
distinguish the two?
> Or do you propose to connect Wiki with an underlying
> document management system?
Underlying what? :) Back in my day, ice-creams were 5c each, school was
a 10 mile walk through blizzards, and filesystems were good enough for
everyone.
But yes, that is a good point. Being able to roll back files is probably
essential for serious doc use. We could simply set up a logrotate script
on the server to back up each day's content.
Also, JSPWiki's "Wiki.jsp?page=<blah>" URI space is horribly non-portable
and un-cool[1], but that can be fixed in 5 minutes with
request.getPathInfo(). Perhaps we could introduce a '@cocoon-version
{2.1|2.0.x}' tag to the cwiki syntax. So Wiki.jsp?page=CocoonCaching
with:
@cocoon-version 2.0.4 -> has URL '/wiki/2.0.4/CocoonCaching'.
@cocoon-version 2.1' -> has URL '/wiki/2.1/CocoonCaching'.
Hmm..
--Jeff
> regards, hussayn
...
[1] http://www.w3.org/Provider/Style/URI.html
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by SAXESS - Hussayn Dabbous <da...@saxess.com>.
Hy;
The mentioning of "Wiki" triggered my curiousity:
If we move all docs to Wiki, then how can we maintain
different release versions of the docs ?
Or will there be only one single document version, that
fits for all released cocoon versions ?
Or do you propose to connect Wiki with an underlying
document management system?
regards, hussayn
Jeff Turner wrote:
> On Wed, Feb 19, 2003 at 03:11:44PM +1100, David Crossley wrote:
>
>>Diana Shannon wrote:
>
> ...
>
>>>I find it a PITA to have to update my HEAD **and** release cvs
>>>branches for simple document updates. It's frustrating to have
>>>doc updates dependencies on a HEAD branch that doesn't reliably
>>>build. I think a separate CVS branch/block/module would be a
>>>definite improvement of the existing situation, but I still think
>>>Wiki should remain the way a majority of people contribute/patch
>>>docs. In fact, I think we should consider moving all existing
>>>Cocoon docs straight to Wiki, so people can patch them there.
>>>I proposed it early, when Cocoon's Wiki started, but I backed
>>>off, given the fact it looked like a way to run around Forrest --
>>>which I didn't want to do. However, now with Wiki's increasing
>>>integration to Forrest (and Steven's ideas of converting wiki
>>>docs via site.xml or similar), it makes increasing sense to me.
>>
>>Will people be able to do both ways - traditional patch/create
>>xdocs in cvs, or via the Wiki?
>
>
> With Chaperon integration, the next version of Forrest should be able to
> handle cwiki and xdoc formats equally well.
>
>
>>Online editing might be okay for people in well-connected countries.
>>However, for the rest of us, working online via dial-up modem through a
>>clumsy web interface is not productive.
>
>
> Well, with the wiki, you click 'edit', make your change, click 'save',
> and that's it.
>
> With CVS, you have to:
>
> - Download a CVS client
> - Install it, Learn how to use it, work out the pserver string, bang
> your head against CVS_RSH, eventually get it right.
> - For many users, discover for the first time that a firewall blocks
> port 2401, and you've wasted your time.
> - Wait n hours for 34M of Cocoon to download
> - find the xdoc you want to edit, build docs, wait, rinse, repeat
> - Search the web for "how to create a patch". Finally figure out 'cvs
> diff -u'.
> - Create a bugzilla account, create a doc enhancement request.
>
> And that's your afternoon, if not your whole day, down the drain.
>
> Moving to Forrest will make the edit turnaround cycle faster, at the
> expense of an extra 10mb download.
>
> So I agree with Diana about moving all docs to the Wiki. It seems the
> best long-term solution, avoiding all the problems that a dual wiki/xdoc
> system would cause.
>
>
> --Jeff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax: +49-221-56011-20
E-Mail: dabbous@saxess.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jeff Turner" <je...@apache.org> wrote:
> So I agree with Diana about moving all docs to the Wiki. It seems the
> best long-term solution, avoiding all the problems that a dual wiki/xdoc
> system would cause.
I disagree on that. IMO the "Wiki" syntax doesn't have the capability to
contextualize the information contained in the document (how can we tell
that a "screenshot" is different from a "configuration file snippet?" - in
"Wiki" it's all a big <PRE>...</PRE> whatever).
Otherwise, what's the point of using XML anyway. I could use FrontPage and
web folders and get done with it...
Pier
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jeff Turner" <je...@apache.org> wrote:
> So I agree with Diana about moving all docs to the Wiki. It seems the
> best long-term solution, avoiding all the problems that a dual wiki/xdoc
> system would cause.
I disagree on that. IMO the "Wiki" syntax doesn't have the capability to
contextualize the information contained in the document (how can we tell
that a "screenshot" is different from a "configuration file snippet?" - in
"Wiki" it's all a big <PRE>...</PRE> whatever).
Otherwise, what's the point of using XML anyway. I could use FrontPage and
web folders and get done with it...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 19 fév 2003, à 08:45 Europe/Zurich, Jeff Turner a écrit :
> ...So I agree with Diana about moving all docs to the Wiki. It seems
> the
> best long-term solution, avoiding all the problems that a dual
> wiki/xdoc
> system would cause.
I tend to agree but OTOH there must be some way for users to find out
about the reliability of a document.
Currently, I think the xdocs are viewed are "official" whereas the wiki
is more like "melting pot" - the difference is easy, even though the
good quality of many wiki docs makes it more blurred in practice.
So I think, if in the future all docs are done on a wiki, some form of
metadata/review system is required so that the state and validity of a
particular document is clearly visible.
-Bertrand
Re: xdoc -> wiki documentation (Re: documentation in separate cvs
module or block)
Posted by Stephan Michels <st...@apache.org>.
On Wed, 19 Feb 2003, Jeff Turner wrote:
> On Wed, Feb 19, 2003 at 03:11:44PM +1100, David Crossley wrote:
> > Diana Shannon wrote:
> >
> > Will people be able to do both ways - traditional patch/create
> > xdocs in cvs, or via the Wiki?
>
> With Chaperon integration, the next version of Forrest should be able to
> handle cwiki and xdoc formats equally well.
I think too ;-)
> > Online editing might be okay for people in well-connected countries.
> > However, for the rest of us, working online via dial-up modem through a
> > clumsy web interface is not productive.
>
> Well, with the wiki, you click 'edit', make your change, click 'save',
> and that's it.
>
> With CVS, you have to:
>
> - Download a CVS client
> - Install it, Learn how to use it, work out the pserver string, bang
> your head against CVS_RSH, eventually get it right.
> - For many users, discover for the first time that a firewall blocks
> port 2401, and you've wasted your time.
> - Wait n hours for 34M of Cocoon to download
> - find the xdoc you want to edit, build docs, wait, rinse, repeat
> - Search the web for "how to create a patch". Finally figure out 'cvs
> diff -u'.
> - Create a bugzilla account, create a doc enhancement request.
>
> And that's your afternoon, if not your whole day, down the drain.
>
> Moving to Forrest will make the edit turnaround cycle faster, at the
> expense of an extra 10mb download.
>
> So I agree with Diana about moving all docs to the Wiki. It seems the
> best long-term solution, avoiding all the problems that a dual wiki/xdoc
> system would cause.
Just a short story of the project, in which I currently working on.
I working in a E-Learning project(The biggest in germany), in which 15
different universities are involved. Our system consist of a Cocoon and
Slide core. We offer two different options to write their content: XML
and Tex. The Tex content will be converted in a internally pipeline into
the XML format. The author can modify their content over WebDAV. The most
used Editor is XMLSpy, which can direct operate with WebDAV. The option,
to write content in a WebForm, is the option, which I missing.
It's sometimes a plague, how stupid our authors are. The funniest thing
was removing the root path *doh*.
I started to believe that a simple WebForm should achieve our needs, since
I was impressed by the popularity of wiki :-/
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 19, 2003 at 03:11:44PM +1100, David Crossley wrote:
> Diana Shannon wrote:
...
> > I find it a PITA to have to update my HEAD **and** release cvs
> > branches for simple document updates. It's frustrating to have
> > doc updates dependencies on a HEAD branch that doesn't reliably
> > build. I think a separate CVS branch/block/module would be a
> > definite improvement of the existing situation, but I still think
> > Wiki should remain the way a majority of people contribute/patch
> > docs. In fact, I think we should consider moving all existing
> > Cocoon docs straight to Wiki, so people can patch them there.
> > I proposed it early, when Cocoon's Wiki started, but I backed
> > off, given the fact it looked like a way to run around Forrest --
> > which I didn't want to do. However, now with Wiki's increasing
> > integration to Forrest (and Steven's ideas of converting wiki
> > docs via site.xml or similar), it makes increasing sense to me.
>
> Will people be able to do both ways - traditional patch/create
> xdocs in cvs, or via the Wiki?
With Chaperon integration, the next version of Forrest should be able to
handle cwiki and xdoc formats equally well.
> Online editing might be okay for people in well-connected countries.
> However, for the rest of us, working online via dial-up modem through a
> clumsy web interface is not productive.
Well, with the wiki, you click 'edit', make your change, click 'save',
and that's it.
With CVS, you have to:
- Download a CVS client
- Install it, Learn how to use it, work out the pserver string, bang
your head against CVS_RSH, eventually get it right.
- For many users, discover for the first time that a firewall blocks
port 2401, and you've wasted your time.
- Wait n hours for 34M of Cocoon to download
- find the xdoc you want to edit, build docs, wait, rinse, repeat
- Search the web for "how to create a patch". Finally figure out 'cvs
diff -u'.
- Create a bugzilla account, create a doc enhancement request.
And that's your afternoon, if not your whole day, down the drain.
Moving to Forrest will make the edit turnaround cycle faster, at the
expense of an extra 10mb download.
So I agree with Diana about moving all docs to the Wiki. It seems the
best long-term solution, avoiding all the problems that a dual wiki/xdoc
system would cause.
--Jeff
xdoc -> wiki documentation (Re: documentation in separate cvs module or block)
Posted by Jeff Turner <je...@apache.org>.
On Wed, Feb 19, 2003 at 03:11:44PM +1100, David Crossley wrote:
> Diana Shannon wrote:
...
> > I find it a PITA to have to update my HEAD **and** release cvs
> > branches for simple document updates. It's frustrating to have
> > doc updates dependencies on a HEAD branch that doesn't reliably
> > build. I think a separate CVS branch/block/module would be a
> > definite improvement of the existing situation, but I still think
> > Wiki should remain the way a majority of people contribute/patch
> > docs. In fact, I think we should consider moving all existing
> > Cocoon docs straight to Wiki, so people can patch them there.
> > I proposed it early, when Cocoon's Wiki started, but I backed
> > off, given the fact it looked like a way to run around Forrest --
> > which I didn't want to do. However, now with Wiki's increasing
> > integration to Forrest (and Steven's ideas of converting wiki
> > docs via site.xml or similar), it makes increasing sense to me.
>
> Will people be able to do both ways - traditional patch/create
> xdocs in cvs, or via the Wiki?
With Chaperon integration, the next version of Forrest should be able to
handle cwiki and xdoc formats equally well.
> Online editing might be okay for people in well-connected countries.
> However, for the rest of us, working online via dial-up modem through a
> clumsy web interface is not productive.
Well, with the wiki, you click 'edit', make your change, click 'save',
and that's it.
With CVS, you have to:
- Download a CVS client
- Install it, Learn how to use it, work out the pserver string, bang
your head against CVS_RSH, eventually get it right.
- For many users, discover for the first time that a firewall blocks
port 2401, and you've wasted your time.
- Wait n hours for 34M of Cocoon to download
- find the xdoc you want to edit, build docs, wait, rinse, repeat
- Search the web for "how to create a patch". Finally figure out 'cvs
diff -u'.
- Create a bugzilla account, create a doc enhancement request.
And that's your afternoon, if not your whole day, down the drain.
Moving to Forrest will make the edit turnaround cycle faster, at the
expense of an extra 10mb download.
So I agree with Diana about moving all docs to the Wiki. It seems the
best long-term solution, avoiding all the problems that a dual wiki/xdoc
system would cause.
--Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: documentation in separate cvs module or block
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 19 fév 2003, à 05:11 Europe/Zurich, David Crossley a écrit
:
> ... We seem to be falling
> into the old trap of dreaming up new tools every time that the
> documentation subject arises.
+1, thanks for pointing this out.
Hopefully we can get the Forrestization done soon and move on.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
documentation in separate cvs module or block
Posted by David Crossley <cr...@indexgeo.com.au>.
Changing thread name for this new subject. Was:
Re: closing cocoon-docs? (was: Cocoon Project Report)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104557472909525
Diana Shannon wrote:
> Steven Noels wrote:
> >
> > On the subject of a separate CVS repository & getting rid
> > of branches for maintaining versions of documentation, this
> > is a personal feeling. For developers who want to maintain
> > documentation, checking out a separate module isn't a big
> > burden, and it would also allow us to give
> > pure-documentation-people CVS commit access.
We talked about this part of the issue before. Anyone who
is working on documentation will also need to tweak other
files in cvs, especially javadoc comments inside java source.
So they need access to all of Cocoon cvs.
> > I think splitting out things will provide people with a
> > cleaner (less daunting) work environment.
If we separate the docs, then how will the effort proceed
to create generated documentation direct from the java source.
> I find it a PITA to have to update my HEAD **and** release cvs
> branches for simple document updates. It's frustrating to have
> doc updates dependencies on a HEAD branch that doesn't reliably
> build. I think a separate CVS branch/block/module would be a
> definite improvement of the existing situation, but I still think
> Wiki should remain the way a majority of people contribute/patch
> docs. In fact, I think we should consider moving all existing
> Cocoon docs straight to Wiki, so people can patch them there.
> I proposed it early, when Cocoon's Wiki started, but I backed
> off, given the fact it looked like a way to run around Forrest --
> which I didn't want to do. However, now with Wiki's increasing
> integration to Forrest (and Steven's ideas of converting wiki
> docs via site.xml or similar), it makes increasing sense to me.
Will people be able to do both ways - traditional patch/create
xdocs in cvs, or via the Wiki? Online editing might be okay
for people in well-connected countries. However, for the
rest of us, working online via dial-up modem through a clumsy
web interface is not productive.
We should take this one step at a time. We seem to be falling
into the old trap of dreaming up new tools every time that the
documentation subject arises.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: closing cocoon-docs? (was: Cocoon Project Report)
Posted by David Crossley <cr...@indexgeo.com.au>.
Steven Noels wrote:
>
> Sure, David - fully aware of that. My 'big hidden agenda' (duh) was to
> add a first step to the main cocoon build, so that others could jump in
> and expand. ...
Moving this part of the discussion over to cocoon-docs:
Re: [PROPOSAL] Use Forrest to build Cocoon docs
http://marc.theaimsgroup.com/?l=xml-cocoon-docs&m=104562792618462
> On the subject of a separate CVS repository [for xdocs] ...
Moving this part of the discussion into a new cocoon-dev thread:
Re: documentation in separate cvs module or block
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104562791318443
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Use Forrest to build Cocoon docs
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 19 fév 2003, à 05:11 Europe/Zurich, David Crossley a écrit
:
> ...For example, how does the
> Cocoon webapp continue to work with the new documentation
> v11 format. I expect that all the documentation stylesheets
> and documentation/sitemap.xmap need to change too.
IMHO maintaining both sets of documentation (Forrest and non-Forrest
versions) would be confusing for users and a waste of energy for
contributors.
As we're going to use Forrest, I'd generate all docs with Forrest and
remove the existing standalone stuff.
Technically I think this requires having a binary version of Forrest in
our CVS, used as a blackbox tool to generate the docs. It won't help
make our CVS codebase smaller, but is there another way? This is really
what we want to do conceptually, use Forrest as a stable tool for our
docs.
> ...The last
> time we started raising the associated issues, everyone
> went quiet for many months.
On my part it is mainly due to events unrelated to Cocoon, but I must
admit some uncertainty about exactly what is required to move our docs
to Forrest, which made me even quieter than I should have been. I'm
probably not alone in this case.
> ...At some stage we need to just do the once-off conversion,
> and then pick up the pieces.
Yes. Going concrete would certainly help, so how about:
-adding a binary version of Forrest (including Cocoon, weird but
required IMHO) to the CVS, in /tools
-using a separate build.xml (called from the main one) to build the
docs using Forrest
-doing this on a CVS branch until the Forrestized docs are usable
Whaddyathink?
-Bertrand
Re: [PROPOSAL] Use Forrest to build Cocoon docs
Posted by David Crossley <cr...@indexgeo.com.au>.
Moved from the cocoon-dev thread to cocoon-docs. Was:
Re: closing cocoon-docs? (was: Cocoon Project Report)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104557472909525
Diana Shannon wrote:
> Steven Noels wrote:
> > David Crossley wrote:
> >>
> >> I thought that "square one" was working out the proposal
> >> to use Forrest to process the Cocoon docs. That conversion
> >> from docv10->docv11 is a part of the process.
> >> http://wiki.cocoondev.org/Wiki.jsp?page=ForrestProposal
>
> > Sure, David - fully aware of that. My 'big hidden agenda' (duh)
> > was to add a first step to the main cocoon build, so that
> > others could jump in and expand.
Yikes, please no hidden agenda. Our plan with that proposal
was to initiate a co-ordinated effort.
> > That doc makes reference to a trail-run-F target
> > which was buried somewhere in Forrest and since it is only
> > of limited concern to Forrest, I wonder why it should be there.
>
> This was based on very helpful advice Nicola Ken provided me
> off-list as I was working on the transition. Because the Forrest
> transition work was a WIP, it seemed inappropriate to place them
> in Cocoon's CVS. Given the fact that Forrest's ability to mount
> "external" xdocs is fundamental, it seemed appropriate to place
> the transition files there.
>
> > Also, I figured a mass-convert to the new format would make it
> > easier to start the clean-up work.
>
> I guess I don't understand what you mean by a mass-convert. We've
> already done that, haven't we?
We have only done an experiment based on Diana's Wiki doc
HowToForrestTransition. The conversion of xdocs from v10 to v11
format is a once-off task, but there are many ramifications.
Hence the Wiki doc ForrestProposal to attempt some co-ordinated
plan for doing the whole job.
> All that remains are tweaking a few configuration files.
> Have you tried using the existing files David and I developed?
I think much more is involved. For example, how does the
Cocoon webapp continue to work with the new documentation
v11 format. I expect that all the documentation stylesheets
and documentation/sitemap.xmap need to change too.
---O---
Let us not dampen anyone's enthusiasm on this. The last
time we started raising the associated issues, everyone
went quiet for many months.
At some stage we need to just do the once-off conversion,
and then pick up the pieces. This would be better done
before Cocoon-2.1 is released.
--David
Re: closing cocoon-docs? (was: Cocoon Project Report)
Posted by Diana Shannon <sh...@apache.org>.
On Tuesday, February 18, 2003, at 03:56 AM, Steven Noels wrote:
> Sure, David - fully aware of that. My 'big hidden agenda' (duh) was to
> add a first step to the main cocoon build, so that others could jump in
> and expand. That doc makes reference to a trail-run-F target which was
> buried somewhere in Forrest and since it is only of limited concern to
> Forrest, I wonder why it should be there.
This was based on very helpful advice Nicola Ken provided me off-list as
I was working on the transition. Because the Forrest transition work was
a WIP, it seemed inappropriate to place them in Cocoon's CVS. Given the
fact that Forrest's ability to mount "external" xdocs is fundamental, it
seemed appropriate to place the transition files there.
> Also, I figured a mass-convert to the new format would make it easier
> to start the clean-up work.
I guess I don't understand what you mean by a mass-convert. We've
already done that, haven't we? All that remains are tweaking a few
configuration files. Have you tried using the existing files David and I
developed?
> On the subject of a separate CVS repository & getting rid of branches
> for maintaining versions of documentation, this is a personal feeling.
> For developers who want to maintain documentation, checking out a
> separate module isn't a big burden, and it would also allow us to give
> pure-documentation-people CVS commit access. I think splitting out
> things will provide people with a cleaner (less daunting) work
> environment.
I find it a PITA to have to update my HEAD **and** release cvs branches
for simple document updates. It's frustrating to have doc updates
dependencies on a HEAD branch that doesn't reliably build. I think a
separate CVS branch/block/module would be a definite improvement of the
existing situation, but I still think Wiki should remain the way a
majority of people contribute/patch docs. In fact, I think we should
consider moving all existing Cocoon docs straight to Wiki, so people can
patch them there. I proposed it early, when Cocoon's Wiki started, but I
backed off, given the fact it looked like a way to run around Forrest --
which I didn't want to do. However, now with Wiki's increasing
integration to Forrest (and Steven's ideas of converting wiki docs via
site.xml or similar), it makes increasing sense to me.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: closing cocoon-docs? (was: Cocoon Project Report)
Posted by Steven Noels <st...@outerthought.org>.
David Crossley wrote:
> I thought that "square one" was working out the proposal
> to use Forrest to process the Cocoon docs. That conversion
> from docv10->docv11 is a part of the process.
> http://wiki.cocoondev.org/Wiki.jsp?page=ForrestProposal
Sure, David - fully aware of that. My 'big hidden agenda' (duh) was to
add a first step to the main cocoon build, so that others could jump in
and expand. That doc makes reference to a trail-run-F target which was
buried somewhere in Forrest and since it is only of limited concern to
Forrest, I wonder why it should be there. Also, I figured a mass-convert
to the new format would make it easier to start the clean-up work.
On the subject of a separate CVS repository & getting rid of branches
for maintaining versions of documentation, this is a personal feeling.
For developers who want to maintain documentation, checking out a
separate module isn't a big burden, and it would also allow us to give
pure-documentation-people CVS commit access. I think splitting out
things will provide people with a cleaner (less daunting) work
environment. That's at least what the Wiki is teaching me. All IMHO, of
course.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: closing cocoon-docs? (was: Cocoon Project Report)
Posted by David Crossley <cr...@indexgeo.com.au>.
Steven Noels wrote:
> Sylvain Wallez wrote:
> >David Crossley wrote:
> >> Actually, the cocoon-docs list has had pathetic uptake.
> >> Is that because people are leaving documentation to be done
> >> by the mysterious "other people"?
> >>
> >
> > So what about closing cocoon-docs ? This would avoid believing some
> > mysterious entities are writing the docs for us...
>
> Naah - I don't know. Even worse, I have been playing with the idea of
> proposing a separate CVS module for docs, in httpd-docs-style. Stuff to
> be moved and developed there:
>
> - the Cocoon public website
> - the docs for the different releases, presumably with each branch
> being brought in its own directory (instead of being managed using CVS
> branches)
> - the framework for building docs & website, which might as well
> become dynamic if we can abuse Pier's presence to have it hosted on nagoya.
>
> I know such thoughts can be regarded as debatable, and it's only based
> on 'belly-thoughts' [BT], but I would bet some Euros on it that this
> could foster a better documentation biosphere.
We do need a better foundation for future doc development.
However, i do not think that we need separate versions of
docs for different releases. A consistent note in each doc
about which version it relates to, might be better.
> The previous week, I wanted to bring in a massive docv10->docv11
> stylesheet into the Cocoon build.xml. But that thing is daunting, the
> Ant 'style' task didn't work as documented, so I was rapidly back at
> square one :-(
>
> I know I could go and fix things, but the amount of existing loose
> threads that need to be taken into account is so damn *huge*
I thought that "square one" was working out the proposal
to use Forrest to process the Cocoon docs. That conversion
from docv10->docv11 is a part of the process.
http://wiki.cocoondev.org/Wiki.jsp?page=ForrestProposal
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Project Report
Posted by Steven Noels <st...@outerthought.org>.
Sylvain Wallez wrote:
>> Actually, the cocoon-docs list has had pathetic uptake.
>> Is that because people are leaving documentation to be done
>> by the mysterious "other people"?
>>
>
> So what about closing cocoon-docs ? This would avoid believing some
> mysterious entities are writing the docs for us...
Naah - I don't know. Even worse, I have been playing with the idea of
proposing a separate CVS module for docs, in httpd-docs-style. Stuff to
be moved and developed there:
- the Cocoon public website
- the docs for the different releases, presumably with each branch
being brought in its own directory (instead of being managed using CVS
branches)
- the framework for building docs & website, which might as well
become dynamic if we can abuse Pier's presence to have it hosted on nagoya.
I know such thoughts can be regarded as debatable, and it's only based
on 'belly-thoughts' [BT], but I would bet some Euros on it that this
could foster a better documentation biosphere.
The previous week, I wanted to bring in a massive docv10->docv11
stylesheet into the Cocoon build.xml. But that thing is daunting, the
Ant 'style' task didn't work as documented, so I was rapidly back at
square one :-(
I know I could go and fix things, but the amount of existing loose
threads that need to be taken into account is so damn *huge*
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: closing cocoon-docs?
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le Lundi, 17 fév 2003, à 14:41 Europe/Zurich, Sylvain Wallez a écrit :
>
>> ...
>> So what about closing cocoon-docs ? This would avoid believing some
>> mysterious entities are writing the docs for us...
>
>
> I'd give a reluctant +1 to this proposal.
I'd be +1 as well.
> Reluctant because I thought a separate docs list would allow more people
> to help with the docs without having to care about core development
> issues - but this has not happened, or not much.
Ok
> Actually the wiki has taken this role by allowing non-developers to make
> great contributions to the overall docs effort, so I agree that going
> back to [doc] subject lines on cocoon-dev makes sense at this point for
> docs-related stuff.
I agree.
> We shouldn't expect miracles from having cocoon-docs or not, but it
> might help at this point.
If there is no documentation team, there should not be a separate CVS
nor a separate mail list.
Also, documentation will have to go along with the blocks that contain
that code and we'll have to write a wiki that is able to generate xml
documentation.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: closing cocoon-docs? (was: Cocoon Project Report)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 18 February 2003 12:37, David Crossley wrote:
> Nicola Ken Barozzi wrote:
> My main point is that we just need to refrain from using the
> term "documentation team". This gives an erroneous impression.
The cocoon-users' wiki effort could perhaps be tapped into better, by granting
some of these users commit rights to the "official" documentation.
Then you would GET the "documentation team".
And keeping the cocoon-docs mailing list as the "market place" for documenters
and developers, such as complex questions that only developers knows, or
planning new features and the documents for it.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: closing cocoon-docs? (was: Cocoon Project Report)
Posted by Stefano Mazzocchi <st...@apache.org>.
David Crossley wrote:
> My main point is that we just need to refrain from using the
> term "documentation team". This gives an erroneous impression.
I will, no matter what cocoon-docs will be.
Apologies if this has caused troubles.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: closing cocoon-docs? (was: Cocoon Project Report)
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
> Bertrand Delacretaz wrote:
> > Sylvain Wallez a écrit :
> >
> >> ...
> >> So what about closing cocoon-docs ? This would avoid believing some
> >> mysterious entities are writing the docs for us...
> >
> > I'd give a reluctant +1 to this proposal.
>
> I'd give a sure -1 to this proposal ;-)
>
> > Reluctant because I thought a separate docs list would allow more people
> > to help with the docs without having to care about core development
> > issues - but this has not happened, or not much.
>
> It has. It allows people to help with the docs without having to care
> about core development issues. It has ups and downs, but IMHO the
> traffic is not bad at all.
>
> > Actually the wiki has taken this role by allowing non-developers to make
> > great contributions to the overall docs effort, so I agree that going
> > back to [doc] subject lines on cocoon-dev makes sense at this point for
> > docs-related stuff.
>
> And cocoon-docs is really the list where it's easy to overview such
> contributions. cocoon-dev alrealy has a too high mail count, and all the
> wiki diffs here would make the noise too high.
>
> Instead of closing cocoon-docs, I would suggest that the committers
> should go on cocoon-docs too.
I agree with Nicola Ken. Rather than closing the facilities,
we need to utilise them properly. Actually, back when we were
talking about starting the cocoon-docs list, it was already
suggested that it would only work if all committers were on
that list and if doc-related discussion happened there rather
than just Cc from elsewhere.
My main point is that we just need to refrain from using the
term "documentation team". This gives an erroneous impression.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: closing cocoon-docs? (was: Cocoon Project Report)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bertrand Delacretaz wrote, On 17/02/2003 16.51:
> Le Lundi, 17 fév 2003, à 14:41 Europe/Zurich, Sylvain Wallez a écrit :
>
>> ...
>> So what about closing cocoon-docs ? This would avoid believing some
>> mysterious entities are writing the docs for us...
>
>
> I'd give a reluctant +1 to this proposal.
I'd give a sure -1 to this proposal ;-)
> Reluctant because I thought a separate docs list would allow more people
> to help with the docs without having to care about core development
> issues - but this has not happened, or not much.
It has. It allows people to help with the docs without having to care
about core development issues. It has ups and downs, but IMHO the
traffic is not bad at all.
> Actually the wiki has taken this role by allowing non-developers to make
> great contributions to the overall docs effort, so I agree that going
> back to [doc] subject lines on cocoon-dev makes sense at this point for
> docs-related stuff.
And cocoon-docs is really the list where it's easy to overview such
contributions. cocoon-dev alrealy has a too high mail count, and all the
wiki diffs here would make the noise too high.
Instead of closing cocoon-docs, I would suggest that the committers
should go on cocoon-docs too.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
closing cocoon-docs? (was: Cocoon Project Report)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 17 fév 2003, à 14:41 Europe/Zurich, Sylvain Wallez a écrit :
> ...
> So what about closing cocoon-docs ? This would avoid believing some
> mysterious entities are writing the docs for us...
I'd give a reluctant +1 to this proposal.
Reluctant because I thought a separate docs list would allow more
people to help with the docs without having to care about core
development issues - but this has not happened, or not much.
Actually the wiki has taken this role by allowing non-developers to
make great contributions to the overall docs effort, so I agree that
going back to [doc] subject lines on cocoon-dev makes sense at this
point for docs-related stuff.
We shouldn't expect miracles from having cocoon-docs or not, but it
might help at this point.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Project Report
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
David Crossley wrote:
>Stefano Mazzocchi wrote:
><snip/>
>
>
>>We are also planning to start using Forrest to build our own
>>documentation, even if this will make it a circular dependency (cocoon
>>depends on forrest and forrest depends on cocoon). But this is something
>>the cocoon documentation team will decide with the forrest developers
>>(most of which are also cocoon developers).
>>
>>
>>
><snip/>
>
>
>>As a special note, I would like to mention how the introduction of the
>>Cocoon wiki (hosted personally by Steven Noels' web site
>>www.cocoondev.org) has been seen by the user community as a great tool
>>and has generated very high-quality and useful documentation. The cocoon
>>wiki was also patched to sends diffs to the cocoon-docs@xml.apache.org
>>mail list (the documentation team), providing ownership and oversight.
>>This is seen as a very useful tool by the documentation team.
>>
>>
>
>Would people please stop referring to a "documentation team".
>
>There is no such separate thing.
>
>All that has happened is that there is a new mailing list
>where people should be able to discuss issues that are
>directly related to core documentation.
>
>Actually, the cocoon-docs list has had pathetic uptake.
>Is that because people are leaving documentation to be done
>by the mysterious "other people"?
>
So what about closing cocoon-docs ? This would avoid believing some
mysterious entities are writing the docs for us...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Project Report
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
<snip/>
> We are also planning to start using Forrest to build our own
> documentation, even if this will make it a circular dependency (cocoon
> depends on forrest and forrest depends on cocoon). But this is something
> the cocoon documentation team will decide with the forrest developers
> (most of which are also cocoon developers).
>
<snip/>
>
> As a special note, I would like to mention how the introduction of the
> Cocoon wiki (hosted personally by Steven Noels' web site
> www.cocoondev.org) has been seen by the user community as a great tool
> and has generated very high-quality and useful documentation. The cocoon
> wiki was also patched to sends diffs to the cocoon-docs@xml.apache.org
> mail list (the documentation team), providing ownership and oversight.
> This is seen as a very useful tool by the documentation team.
Would people please stop referring to a "documentation team".
There is no such separate thing.
All that has happened is that there is a new mailing list
where people should be able to discuss issues that are
directly related to core documentation.
Actually, the cocoon-docs list has had pathetic uptake.
Is that because people are leaving documentation to be done
by the mysterious "other people"?
All developers and users should be helping with building docs.
So that means that the documentation team is comprised of everyone,
not just those few who have bothered to subscribe to cocoon-docs.
***************************************************************
********** **********
********** There is no separate "documentation team" **********
********** **********
***************************************************************
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon Project Report
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
> Pier Fumagalli [...]
> is helping us a lot with infrastructure issues directly, reducing the
> work on infrastructure@ directly.
Huh? :-) It's 2 weeks I ain't doin' jack for you guys! :-)
> Stefano Mazzocchi - V.P. Apache Cocoon
This actually made me laugh!!! :-)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org