From: "TREGAN Fabien" <[EMAIL PROTECTED]>

>
> >De: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> >
> >Hi Diana,
> >
> >I can only speak for myself, but this process seems a little bit
> >over complicated as it involves many stages. We don't want to print
> >a book, we only want good documentation.
> >
> >I can live with your steps 1-3 and would change step 4 and 5:
> >
> >4. Author sends docs as patch or commits it into scratchpad docs
> >
> >5. Documentation Coordinator (or someone else) picks up doc,
> >   revises it and applies it to the documentation.
> >
> >Now I'm interested in the response :)
>
> I agree : having a doc in scratchpad for quick review, then having them
> moved to core doc even if not perfect, and adding patch from time to time
> seems to be more realistic.

+1

> We must'nt forget that code is still moving and that the doc will have to
be
> patched anyway. (I even do not know if the current HEAD constructor of
> AbstractSAXSource need the Environnement object :) )
>
> mmm, while we are at it : is there a standard notation to tell wich
version
> of cocoon is concerned y a sample, code snipet, note, ... ?

<TOL>
Oh, and since it's easy to make documentation stale, it could be cool if we
come up with a method of warning that documentation is stale.

For example, we could have the author add an indication of how much he
thinks the docs could need to change, and also say which classes it is tied
to.
If the class is not there anymore it means that the doco is out of date, or
if the class size changed considerably since the document commit in CVS.
</TOL>

--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to