You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by Bertrand Delacretaz <bd...@codeconsult.ch> on 2003/04/03 08:46:26 UTC
Do we need to scrap the existing docs and start over?
(Read on - it's not as bad as it seems ;-)
Reading Tony Collen's weblog at
http://manero.org/weblog/archives/000082.html reinforces my thinking
that the current organization does not allow the kind of disruptive
work that is needed to make the docs happen.
The recurrent scenario in the last months is that someone brings a new
idea, the discussion quickly centers around tools instead of content
and after a few days everyone goes back in a wait state as there is no
100% consensus on how to do things. I've been guilty too, I'm not
pointing fingers here but I think this is a reality.
IMHO the main problems are
1) We're afraid of breaking the existing docs or offending their
authors by making big changes to the navigation/layout/content/whatever
2) There is no sandbox where to safely experiment in small steps. The
wiki is good for experimental content but not to work on the
navigation/structure/presentation of the Cocoon web site.
But small steps and concrete results (=documents, navigation, layout,
search features) are needed to converge the excellent ideas that have
been exchanged here in the last few months.
I think it is critical that we allow people to work in small increments
on this move: most probably several of us, like me, can commit small
amounts of time to this here and there, but not the two-weeks full-time
that would be needed for the big reworking that is (IMHO) needed.
Here's what I suggest:
-create a new-docs subdirectory in the (cocoon-2.1 or cocoon-docs) CVS
-configure an alternate Forrest-based docs build using this as input
-use this a a scratchpad to create a new web site with better
navigation and more consistent content, starting from scratch
-gradually bring over the best existing CVS and wiki docs
-switch the web site to new-docs once they are good enough
How does this sound?
-Bertrand
Re: Do we need to scrap the existing docs and start over?
Posted by Steven Noels <st...@outerthought.org>.
On 3/04/2003 15:26 Geoff Howard wrote:
> Are you able/willing to donate it?
Willing for sure, I like writing primer things. Able, I assume this has
to wait until it has been published in the conference proceedings of XML
Europe - I guess. There were no specific copyright waivers or license
transfers, so I assume the copyright is still with me and I can do with
it whatever I want. I'll check with IDEAlliance, and let you guys know.
Thanks for the compliment. :-D
</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: Do we need to scrap the existing docs and start over?
Posted by Geoff Howard <co...@leverageweb.com>.
At 06:50 AM 4/3/2003, you wrote:
>Steven Noels wrote:
>>On 3/04/2003 8:46 Bertrand Delacretaz wrote:
>>
>>>How does this sound?
>>>-Bertrand
>>
>>I am very happy to hear that :-)
>
>Me too.
<snip/>
Speaking of new docs -
Steven, I just read the Cocoon introduction paper you mentioned recently on
the list. It's the best single read introductions to Cocoon I've seen. I
think it would be a significant improvement to the experience of discovering
Cocoon to have that content featured prominently in the new docs moving
forward.
Are you able/willing to donate it?
My time's been very limited lately, but I'll try to pitch in on whatever new
docs movement happens along the lines Bertrand proposed.
Geoff
Re: Do we need to scrap the existing docs and start over?
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
> On 3/04/2003 8:46 Bertrand Delacretaz wrote:
>
>> How does this sound?
>> -Bertrand
>
>
> I am very happy to hear that :-)
Me too.
Feel free to blast/cut/rewrite/reconsider/clean/throw-away anything I've
written without worries of me getting offended in any way :)
Stefano.
Re: Do we need to scrap the existing docs and start over?
Posted by Steven Noels <st...@outerthought.org>.
On 3/04/2003 8:46 Bertrand Delacretaz wrote:
> How does this sound?
> -Bertrand
I am very happy to hear that :-)
</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: xdocs vs. wiki docs (was: ...scrap the existing docs and start over?)
Posted by Diana Shannon <sh...@apache.org>.
On Friday, April 4, 2003, at 04:33 AM, David Crossley wrote:
>>
>> ok - I think we had a nice concept here.
>> (and the Chaperon parser could certainly help a lot for this but let's
>> not talk about tools ;-)
>>
>>> - Leave all the rest -- How-Tos, FAQs, Tutorials, Concepts -- to a
>>> more open content system (via wiki/PHP-notes-like/simple CMS, >
>>> etc.)....
>
> These docs can then directly reference the well-controlled
> core documentation, thus not needing to explain basic
> concepts over and over.
We could also have them on wiki, on non-editable pages.
Diana
Re: xdocs vs. wiki docs (was: ...scrap the existing docs and start
over?)
Posted by David Crossley <cr...@indexgeo.com.au>.
Bertrand Delacretaz wrote:
> Diana Shannon a écrit :
>
> <lots-of-cool-stuff-snipped/>
>
> > ...- separate out all docs relating to project administration,
> > licensing, etc. Keep a single instance of these somewhere. Maintain
> > these in xdocs. Refine/edit/refactor as approach
>
> Let me reformulate to make sure we're in sync:
> Keep the xdocs to the bare minimum: project info, sitemap and
> components reference, that's it?
Core conceptual documentation would also belong in this group.
> All the rest (tutorial, examples, how-tos) is found on the "other doc
> system" mentioned below.
>
> > - Refactor our reference docs to be produced by some kind of
> > auto-generation mechanism...
>
> ok - I think we had a nice concept here.
> (and the Chaperon parser could certainly help a lot for this but let's
> not talk about tools ;-)
>
> > - Leave all the rest -- How-Tos, FAQs, Tutorials, Concepts -- to a
> > more open content system (via wiki/PHP-notes-like/simple CMS, > etc.)....
These docs can then directly reference the well-controlled
core documentation, thus not needing to explain basic
concepts over and over.
--David
Re: xdocs vs. wiki docs (was: ...scrap the existing docs and start
over?)
Posted by Steven Noels <st...@outerthought.org>.
On 4/04/2003 13:40 Diana Shannon wrote:
>> 3) Giving more importance to the wiki might put more strain on the
>> wiki administrator who might have more work fighting with trolls or
>> sabotage. Steven, what do you think?
>
>
> Steven, I volunteer to help. As for trolls, some of this can be
> discouraged with the password-protection front end. I already
> volunteered to help develop that (in an email to Steven off-list) but
> haven't been recruited yet. Seems to me we could have a rotating
> committers/users on troll-watch duties, if these trolls don't get dealt
> with informally.
Sorry, I haven't quite dealt with my recent inbox inundation yet, but of
course your help would be very welcome. I have been talking offline with
the JSPWiki folks and apparently they are up to something themselves.
With regards to trolls, there was yet another one (164.164.87.54) today,
and 62.225.183.250 yesterday, 12.222.230.229 the week before, etc etc
etc :-(
On my weblog, I started to block IP ranges for submitting comments. Sigh.
</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: xdocs vs. wiki docs (was: ...scrap the existing docs and start over?)
Posted by Diana Shannon <sh...@apache.org>.
On Friday, April 4, 2003, at 08:33 AM, Bertrand Delacretaz wrote:
>
>>> 1) There must be a way for users to know if a given version of a wiki
>>> doc has been reviewed/validated by committers, and by whom, so they
>>> can estimate the reliability of the document.
>>> (I have ideas for this based on status files stored in CVS and
>>> dynamically read by a JSPWiki plugin from viewcvs, but let's not talk
>>> about tools ;-)
>>
>> Ok, let's try. However, this might be hard to do consistently,
>> especially with docs that relate to a particular configuration. Plus,
>> what if a user introduces something incorrect after it's been
>> validated? I know they could check diffs against a validation date,
>> but, that starts to get complicated.
>
> It might not be that hard if the wiki page revision has a unique ID
> (maybe simply the file time), then we could have a status file in CVS
> like
>
> SomeFunnyWikiPage 2002-02-14 12:04:06 user:joe version:2.1
> comments:intro needs some work, but otherwise ok
>
> Which could be translated to a small status table in the wiki page
> (after being pulled from CVS by JSPWiki over the viewcvs interface), in
> a different color if the file date is not what is in the status file
> anymore. "joe" is the committer who validated, "2.1" is the version
> against which this page was validated and the rest are comments.
>
> This needs a JSPplugin to produce the status table but IMHO is not too
> hard to maintain.
> Maybe using a java properties file for the status file would make the
> plugin implementation easier and more flexible.
Well, it's my understanding we could Forrestize wiki docs, say for a
release publication need, by parsing the structured text contained in
jspwiki.fileSystemProvider.pageDir. Now of course, you could embed a tag
with this version content within the editable page text, as per
variables shown in pages like SystemInfo, but that would require users
to include this tag every time they set up a new page. How would you
handle this?
Diana
Re: xdocs vs. wiki docs (was: ...scrap the existing docs and start over?)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Vendredi, 4 avr 2003, à 13:40 Europe/Zurich, Diana Shannon a écrit :
> On Friday, April 4, 2003, at 02:20 AM, Bertrand Delacretaz wrote:
>
>> Although I've been and still am a strong advocate for wikis,
>
> I appreciate that, especially now. I consider myself a convert because
> of advocates like you. :-)
Thanks!
The relationship between the Cocoon project and wikis might deserve a
book at some point ;-)
>> 1) There must be a way for users to know if a given version of a wiki
>> doc has been reviewed/validated by committers, and by whom, so they
>> can estimate the reliability of the document.
>> (I have ideas for this based on status files stored in CVS and
>> dynamically read by a JSPWiki plugin from viewcvs, but let's not talk
>> about tools ;-)
>
> Ok, let's try. However, this might be hard to do consistently,
> especially with docs that relate to a particular configuration. Plus,
> what if a user introduces something incorrect after it's been
> validated? I know they could check diffs against a validation date,
> but, that starts to get complicated.
It might not be that hard if the wiki page revision has a unique ID
(maybe simply the file time), then we could have a status file in CVS
like
SomeFunnyWikiPage 2002-02-14 12:04:06 user:joe version:2.1
comments:intro needs some work, but otherwise ok
Which could be translated to a small status table in the wiki page
(after being pulled from CVS by JSPWiki over the viewcvs interface), in
a different color if the file date is not what is in the status file
anymore. "joe" is the committer who validated, "2.1" is the version
against which this page was validated and the rest are comments.
This needs a JSPplugin to produce the status table but IMHO is not too
hard to maintain.
Maybe using a java properties file for the status file would make the
plugin implementation easier and more flexible.
In this way committers could safely validate wiki content, and the
validations would be marked as stale if the pages are edited later on.
We don't need to go too far in this right now, I think there is a way
if we want to implement this but it is not the highest priority.
>
>> 2) There must be a way to archive the wiki docs when a release is
>> done so people using older releases can get docs that are in sync.
>> (possible with a static archive of the wiki HTML pages)
>
> Good point. I also think we need a way to generate a list of
> "approved" wiki pages for such releases, for example, without sandbox
> pages, etc.. I was hoping this could happen with wiki -> xdocs (via
> Forrest) with a linkmap that controlled which links expanded. Haven't
> had time to experiment though.
With the above mechanism, approved pages would be easily identifed.
<snip-agreed/>
-Bertrand
Re: xdocs vs. wiki docs (was: ...scrap the existing docs and start over?)
Posted by Diana Shannon <sh...@apache.org>.
On Friday, April 4, 2003, at 02:20 AM, Bertrand Delacretaz wrote:
> Although I've been and still am a strong advocate for wikis,
I appreciate that, especially now. I consider myself a convert because
of advocates like you. :-)
> I see three problems with this solution:
>
> 1) There must be a way for users to know if a given version of a wiki
> doc has been reviewed/validated by committers, and by whom, so they can
> estimate the reliability of the document.
> (I have ideas for this based on status files stored in CVS and
> dynamically read by a JSPWiki plugin from viewcvs, but let's not talk
> about tools ;-)
Ok, let's try. However, this might be hard to do consistently,
especially with docs that relate to a particular configuration. Plus,
what if a user introduces something incorrect after it's been validated?
I know they could check diffs against a validation date, but, that
starts to get complicated.
> 2) There must be a way to archive the wiki docs when a release is done
> so people using older releases can get docs that are in sync.
> (possible with a static archive of the wiki HTML pages)
Good point. I also think we need a way to generate a list of "approved"
wiki pages for such releases, for example, without sandbox pages, etc..
I was hoping this could happen with wiki -> xdocs (via Forrest) with a
linkmap that controlled which links expanded. Haven't had time to
experiment though.
> 3) Giving more importance to the wiki might put more strain on the wiki
> administrator who might have more work fighting with trolls or
> sabotage. Steven, what do you think?
Steven, I volunteer to help. As for trolls, some of this can be
discouraged with the password-protection front end. I already
volunteered to help develop that (in an email to Steven off-list) but
haven't been recruited yet. Seems to me we could have a rotating
committers/users on troll-watch duties, if these trolls don't get dealt
with informally.
Diana
xdocs vs. wiki docs (was: ...scrap the existing docs and start over?)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 3 avr 2003, à 16:33 Europe/Zurich, Diana Shannon a écrit :
<lots-of-cool-stuff-snipped/>
> ...- separate out all docs relating to project administration,
> licensing, etc. Keep a single instance of these somewhere. Maintain
> these in xdocs. Refine/edit/refactor as approach
Let me reformulate to make sure we're in sync:
Keep the xdocs to the bare minimum: project info, sitemap and
components reference, that's it?
All the rest (tutorial, examples, how-tos) is found on the "other doc
system" mentioned below.
> - Refactor our reference docs to be produced by some kind of
> auto-generation mechanism...
ok - I think we had a nice concept here.
(and the Chaperon parser could certainly help a lot for this but let's
not talk about tools ;-)
> - Leave all the rest -- How-Tos, FAQs, Tutorials, Concepts -- to a
> more open content system (via wiki/PHP-notes-like/simple CMS, > etc.)....
ok, I see your point with allowing users to contribute directly.
What we have today to implement this is the existing wiki - we don't
want three different doc mechanisms, do we?
Although I've been and still am a strong advocate for wikis, I see
three problems with this solution:
1) There must be a way for users to know if a given version of a wiki
doc has been reviewed/validated by committers, and by whom, so they can
estimate the reliability of the document.
(I have ideas for this based on status files stored in CVS and
dynamically read by a JSPWiki plugin from viewcvs, but let's not talk
about tools ;-)
2) There must be a way to archive the wiki docs when a release is done
so people using older releases can get docs that are in sync.
(possible with a static archive of the wiki HTML pages)
3) Giving more importance to the wiki might put more strain on the wiki
administrator who might have more work fighting with trolls or
sabotage. Steven, what do you think?
If we can solve these issues I'm +1 on this concept: minimal xdocs, the
rest on the wiki.
-Bertrand
Re: Do we need to scrap the existing docs and start over?
Posted by Diana Shannon <sh...@apache.org>.
On Thursday, April 3, 2003, at 01:46 AM, Bertrand Delacretaz wrote:
>
> Here's what I suggest:
> -create a new-docs subdirectory in the (cocoon-2.1 or cocoon-docs) CVS
> -configure an alternate Forrest-based docs build using this as input
> -use this a a scratchpad to create a new web site with better
> navigation and more consistent content, starting from scratch
> -gradually bring over the best existing CVS and wiki docs
> -switch the web site to new-docs once they are good enough
>
> How does this sound?
Sorry, it still feels top-down and it overlooks our richest, biggest
resource -- users who contribute via wiki. The best thing that has
happened to docs over the past year is wiki. What you are proposing
above, unless it remains easily editable/note-able/accessible by our
community via wiki or some other mechanism, is going to grow stale down
the road. Just because it may be better than what we have now, it will
remain incomplete (I still see no dedicated team of authors among us to
fill in the current gaps), and after a while it will grow out of date
again -- if users can't easily update it.
Furthermore, look at our content. A good chunk of it is about the
project, having nothing to do with learning/using cocoon. Most of the
rest is reference material with concept docs. We have a handful of
tutorials, how-tos, and faqs.
Given our limited committer resources, here's how I'd approach this.
- separate out all docs relating to project administration, licensing,
etc. Keep a single instance of these somewhere. Maintain these in xdocs.
Refine/edit/refactor as approach
- Refactor our reference docs to be produced by some kind of
auto-generation mechanism, as discussed and partially prototyped earlier
(by Bertrand, Andy, Berni, and others) on this list. Much of the
existing reference docs content can be used for this. Sometimes I think
reference docs are the strongest domain of an open source project, what
it can and should do very well. I'm honestly not sure about other doc
types, whether an open source software projects can produce decent user
docs like how-tos and user manuals without a dedicated team of authors,
not doc tool builders.
- Leave all the rest -- How-Tos, FAQs, Tutorials, Concepts -- to a more
open content system (via wiki/PHP-notes-like/simple CMS, etc.). Note, I
fully expect committers to contribute to wiki, as they already are. This
can develop into a full blown CMS down the road. For the moment, I see a
wiki-docs generation handled elegantly by Forrest, with a few new
features perhaps.
- If and when a committed group of authors appear, group write a better
user manual. Or start one on wiki with a lot of guidelines/templates.
However, I see this as a low priority for this, given the excellent
books we already have.
Given our resources, given our users, I fail to see why we should
perpetuate the closed-cvs-xdoc-editing system like the above. It doesn't
produce timely content. We've had it for a long time. Simply rearranging
content -- weeding out bad, even bringing in new stuff from wiki, adding
tabs, changing navigation -- is like rearranging the deck chairs on the
sinking Titanic. Please note that I'm NOT talking about Forrest, just
about a cvs-based editing system. Cocoon is a vibrant, dynamic,
innovative software project. I just don't think a cvs-based doc system,
maintained primarily by committers and a few committed users, will ever
be able to keep up with Cocoon's evolution, articulate useful
information about the rich variety of problems Cocoon can solve, without
the help of our wide user base.
Diana
Re: Do we need to scrap the existing docs and start over?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 3 avr 2003, à 11:47 Europe/Zurich, Andrew Savory a écrit :
> ...
> - can we be sure we have enough time to rebuild all docs from scratch?
I'm not thinking about rebuilding *docs* from scratch, but rather
reorganizing, sorting and moving old docs to the new stuff.
Initial work would be very little writing, maybe putting some "this
needs to be written" pages here and there.
> ...
> - can we be sure that in the interim, three sets (2.0, 2.1, -docs)
> will be
> maintained?
The whole thing shouldn't take more than (say) 4 weeks, otherwise it's
not worth it IMHO.
I can commit a few hours a week to this.
Do we really want to maintain 2.0 docs? Is anyone willing to commit
time to this? I'm not.
In my view it would be minimal work on 2.1, and concentrating on
new-docs with the goal of releasing them soon.
> ...I also *really* want to get my thoughts on merging/versioning and
> literate
> programming together before we do this (since it should reduce effort
> significantly in the long term), but I'm fighting with several
> deadlines
> that I won't be clear of until after the weekend.
ok - it doesn't prevent us to start working on the docs
outline/navigation anyway.
-Bertrand
Re: Do we need to scrap the existing docs and start over?
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi,
In general, I think that building a new outline from scratch and then
populating with existing/new content is a good idea, as it allows us to
break from the organically-grown content where it's hard to find what you
are looking for.
Having a clean, properly structured documentation tree where everything is
sensibly / logically placed is a big +1. I see the biggest issue here as a
clean split between reference material and usage/howto material.
As ever, we need to be careful not to throw the baby out with the
bathwater though:
- can we be sure we have enough time to rebuild all docs from scratch?
- can we be sure that in the interim, three sets (2.0, 2.1, -docs) will be
maintained?
I also *really* want to get my thoughts on merging/versioning and literate
programming together before we do this (since it should reduce effort
significantly in the long term), but I'm fighting with several deadlines
that I won't be clear of until after the weekend.
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
This is not an official statement or order. Web: www.luminas.co.uk
Re: Do we need to scrap the existing docs and start over?
Posted by Tony Collen <tc...@neuagency.com>.
On Thu, 3 Apr 2003, Bertrand Delacretaz wrote:
<snip/>
> In view of a possible cocoon-docs repository mapped to the existing
> src/documentation subtree, I think the new-documentation directory has
> to be under src/documentation. But let's focus on concepts and goals
> instead of tools ;-)
I just spent the past hour creating a spreadsheet of all the docs. Not
done yet. Tired. Will work more tomorrow.
Zzzzz...
Tony
--
Tony Collen
ICQ: 12410567
--
Cocoon: Internet Glue (A Cocoon Weblog)
http://manero.org/weblog/
--
Re: Do we need to scrap the existing docs and start over?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 3 avr 2003, à 09:29 Europe/Zurich, Tony Collen a écrit :
> ...Navigation isn't really a concern either,
> except for maybe linking to other documents....
By Navigation I mean Forrest tabs and the like, that is "how do users
see the docs", something like the table of contents that you suggested.
I think this is what you call Organization.
But instead of making more suggestions about this Navigation I'd go for
actually implementing one or several (using CVS branches) new versions
of the web site with minimal content, just to judge the Navigation (or
whatever we want to call it) before inserting more content (which would
mostly be copied from the existing docs I assume).
> ...So perhaps it's not knowing
> how documents are rendered/named/whatever in relation to their
> position in
> the CVS tree....
Ok - that's where a sandbox would help too.
> ...How about a new-docs block or something? Then when we think they're
> 'ready', switch them over to replace what's there.
>
> If not a block, let's at least get a new-documentation directory
> setup...
In view of a possible cocoon-docs repository mapped to the existing
src/documentation subtree, I think the new-documentation directory has
to be under src/documentation. But let's focus on concepts and goals
instead of tools ;-)
-Bertrand
Re: Do we need to scrap the existing docs and start over?
Posted by Tony Collen <tc...@neuagency.com>.
On Thu, 3 Apr 2003, Bertrand Delacretaz wrote:
> Reading Tony Collen's weblog at
> http://manero.org/weblog/archives/000082.html reinforces my thinking
> that the current organization does not allow the kind of disruptive
> work that is needed to make the docs happen.
Ohhh. Readers! Always a nice surprise :)
<snip/>
> 1) We're afraid of breaking the existing docs or offending their
> authors by making big changes to the navigation/layout/content/whatever
Hmm. I'd say most of it is the first one (breaking the docs). But that
might just be because I'm still not 100% comfortable with the source
directory layout.
We should all know layout is not a concern to us (let the Forrest
stylesheets worry about it), and Navigation isn't really a concern either,
except for maybe linking to other documents. So perhaps it's not knowing
how documents are rendered/named/whatever in relation to their position in
the CVS tree.
> 2) There is no sandbox where to safely experiment in small steps. The
> wiki is good for experimental content but not to work on the
> navigation/structure/presentation of the Cocoon web site.
>
> But small steps and concrete results (=documents, navigation, layout,
> search features) are needed to converge the excellent ideas that have
> been exchanged here in the last few months.
Here's our main concerns in order of importance:
1. Content
2. Organization
We already have lots of 1, which is actually a problem now because it is
loosely organized. When I wrote out that big outline of what a "Cocoon
Manual" would be, Diana mentioned something to the effect that it was a
very "top-down" approach, which I took to mean that I just sort of made it
up without actually looking to see what we have. Which is exactly what I
did. Now, however, I see that what we need to do is take #1 and apply #2
to it.
That is, based on the content we have, what organization can come of it?
And once we have Organization, Navigation will organically come from it.
And we still don't have to worry about stuff like layout and presentation
:)
> I think it is critical that we allow people to work in small increments
> on this move: most probably several of us, like me, can commit small
> amounts of time to this here and there, but not the two-weeks full-time
> that would be needed for the big reworking that is (IMHO) needed.
Oh man, If I could spare 2 weeks paid vacation, I'd already have something
big done. Oh well.. that's what I get for being a full time student and
working part-time as well.
> Here's what I suggest:
> -create a new-docs subdirectory in the (cocoon-2.1 or cocoon-docs) CVS
> -configure an alternate Forrest-based docs build using this as input
> -use this a a scratchpad to create a new web site with better
> navigation and more consistent content, starting from scratch
> -gradually bring over the best existing CVS and wiki docs
> -switch the web site to new-docs once they are good enough
How about a new-docs block or something? Then when we think they're
'ready', switch them over to replace what's there.
If not a block, let's at least get a new-documentation directory setup.
New Docs on the Block.... oh man.. yeah, time for bed.
G'night.
Tony
--
Tony Collen
ICQ: 12410567
--
Cocoon: Internet Glue (A Cocoon Weblog)
http://manero.org/weblog/
--