[ZDP] Re: new approach?

Michel Pelletier michel@digicool.com
Tue, 07 Nov 2000 15:00:33 -0800

Rik Hoekstra wrote:
> > > you). On the other hand, I did look at it before and was not convinced
> it
> > > was much better than we had come up with... SO I wouldn't bother too
> much
> >
> > *I* would.  It represents a large fraction of what Amos and I did this
> > week.
> woops! Sorry. No offense meant

None taken.

> > We are not trying to create something to replace your efforts, we are
> > organizing official Zope documentation in one area.  This is a subset of
> > your greater effort to centralize and organize all docs.  Since official
> > docs are, well, official, and they go through a discreet process, this
> > area is very important.  You may have seen an earlier draft of the page
> > where we had too broad of a scope, we have narrowed it down a bit.
> >
> Ok, I probably did not get it at the time. The official docs and their
> presentation are of course your (DC's) responsability. That _is_ something
> else than we're doing.
> Ethan will coordinate this stuff, I hope, so that we don't accidentally end
> up doing the same thing twice?

Yes, Ethan is in charge of this aspect.  We are in charge of the
documentation process proposal at:


A very important part of this Wiki you all should look at is:


This is really the core discussion of the delivery issue (for more
detail on how delivery fits into the process, see:)


Under 'delivery'.

Amos and I were under the impression that we were charged with the task
of organizing 'official' documentation.  I'm  not sure why we were given
this impression, and the task is clearly Ethan's.  We hope you guys like
some of the ideas we came up with in /Documentation/new and use them,
and we will, of course, pitch in our two cents on your
DocumentationDelivery Wiki.

Collaboration here is important.  It sounds to me like you guys were
mixing your own process in with how to deliver the artifacts of that
process.  I don't think these issues should be mixed like this.  Both
concepts should be discussed in the open in their own areas with
interlinking between important issues.  In fact, the page above on
DocumentationDelivery should link to a different fishbowl proposal that
Ethan is in charge of that discusses delivery issues, not process
issues.  There is some interesting circular reference here, delivery is
part of the process, and the process creates artifacts that must be
delivered effectively.