On Friday, April 26, 2002, David Crossley wrote:
>
>>| - FAQ Document -|
>>
>> Purpose
>> Addresses holes or ambiguity in docs, bugs in code.
>
> Has many pruposes. Also is something that gets asked frequently.
> Some things are so fundamentally hard to grasp, or so commonly
> misun
>| - FAQ Document -|
>
> Purpose
> Addresses holes or ambiguity in docs, bugs in code.
Has many pruposes. Also is something that gets asked frequently.
Some things are so fundamentally hard to grasp, or so commonly
misunderstood. This is not due to deficiency in any doco. This
type
Diana Shannon wrote:
> Bertrand Delacretaz wrote:
>
> > 1) Tracks:
> > it might be worthwile at some point to create "tracks" into the
> > documentation, task-oriented reading guides.
> >
> > For example: if you want to publish static XML to HTML, here's your
> > reading
> > list: "FAQ 232, FAQ
On Friday 26 April 2002 11:19, Diana Shannon wrote:
>. . .
> Do you think these need separate classification, or should they be
> how-tos (with links to other how-tos), categorized as tracks?
>. . .
I see the tracks as part of the navigation, which could be:
a) search-based ("googling through th
On April 26, 2002, Bertrand Delacretaz wrote:
Very helpful comments, Bert.
> 1) Tracks:
> it might be worthwile at some point to create "tracks" into the
> documentation, task-oriented reading guides.
>
> For example: if you want to publish static XML to HTML, here's your
> reading
> list: "FA
Great work Diana, your plan looks really cool to me!
There are two additions that I'm thinking of:
1) Tracks:
it might be worthwile at some point to create "tracks" into the
documentation, task-oriented reading guides.
For example: if you want to publish static XML to HTML, here's your readi
Issue
How should we classify Cocoon user documents to channel future content
contributions -- from developers and users alike -- most effectively?
What are the implications of such classifications on document structure,
guidelines for contributors, and the Cocoon project's web site
functionali
