Hello,
I don't really want to define a global structure a priori because I
expect each documentation writer will have their own view of how
documentation should be organised. However, we will periodically need
to discuss and agree how to better organise what is already there
(refactoring if
Hi Mark,
let's take it slow and use the dev list for discussions. Marking the
subjects with [Docs] (as you've already done) gives the others the
option to join or ignore as they see fit.
If the volume increases the decision to use another mailing list can
always be taken.
To aid document
Mark Leicester wrote:
Hello,
I don't really want to define a global structure a priori because I
expect each documentation writer will have their own view of how
documentation should be organised. However, we will periodically need
to discuss and agree how to better organise what is already
Hi Helma,
OK, the dev list sounds just fine! What do you think about the
refactoring I'm suggesting? I can do it over the next few hours if you
are agreeable. You are editor-in-chief, so I don't want to start
without your approval!
Also, it occurred to me that perhaps we should delete pages
On 9 Jun 2005, at 15:25, Sylvain Wallez wrote:
Mark Leicester wrote:
Getting started with Cocoon
+ Installing the prerequisites
+ Java
+ Getting the latest release of Cocoon
+ Downloading a Cocoon release
+ Getting Cocoon from the source repository
+ Installing and configuring
Steven Noels wrote:
On 09 Jun 2005, at 15:26, Mark Leicester wrote:
I don't really want to define a global structure a priori because I
expect each documentation writer will have their own view of how
documentation should be organised.
And we now have a system which accommodates this. I
OK, the dev list sounds just fine! What do you think about the
refactoring I'm suggesting? I can do it over the next few
hours if you
are agreeable. You are editor-in-chief, so I don't want to start
without your approval!
:-)
Getting started with Cocoon
+ Installing the prerequisites
Linden H van der (MI) wrote:
Hi Mark,
let's take it slow and use the dev list for discussions. Marking the
subjects with [Docs] (as you've already done) gives the others the
option to join or ignore as they see fit.
If the volume increases the decision to use another mailing list can
always be
Hi Helma,
Fine. I've already thought about the length of the pages currently in
the tutorial, but I'd rather get the stuff in first and refactor later.
Mind you, I don't like pages that consist of a header and one
paragraph.
OK, I'll just add whatever I think is useful as a new page (editing
To aid document reorganisation I think we should encourage a fairly
fine-grained modularity, i.e. single topic pages.
Wouldn't it be a good start to do a smart import of current
xdocs into
new documentation structure?
No offense, but smart import still means going over each and every
Linden H van der (MI) wrote:
To aid document reorganisation I think we should encourage a fairly
fine-grained modularity, i.e. single topic pages.
Wouldn't it be a good start to do a smart import of current
xdocs into
new documentation structure?
No offense, but smart import still means
That was exactly what I proposed. Our target should be a single
documentation source deprecating main docs and wiki. If we
add what is
the easiest now and leave main documentation aside the whole
effort will be incoherent.
True, but let's do one step at a time. The wiki is easier to
Yes, I think we are writing more than a reference manual
here. Perhaps,
at the appropriate places we could also talk about unit testing and
other best practices.
To me it ranges from executive summary to user's guide and tutorials
to developer's guide and reference manual and everything
Le 9 juin 05, à 15:47, Mark Leicester a écrit :
...Also, it occurred to me that perhaps we should delete pages out of
the wiki once they become Daisy-ised. Otherwise we have two
scratchpads. What do you think?..
Yes, it would be good to replace the wiki content by a link to the new
page in
14 matches
Mail list logo
