> > Initially it might be best to group the contributions into a limited
> > set of topics; something like:
> >
> > Installation
> > Site configuration and development
> > Functions: general usage
> > Functions: record types
> > Functions: topic and article functions
> > Functions: person and group functions
> > Functions: host and page functions
> > Functions: style and element functions
> > Functions: other
>
> A relatively easy way to do this would be to setup a topic tree to hold
> comments, and have suptopics under that named by the manual URL, so
> a topic /manualcomments/function.is-topic-owner, /manualcomments/x34,
> etc.
> Each subtopic could collect comments in articles, and the /manual/ page
> can be altered to show those comments. The get_by_name functions from
> tricks
> & tips would make this scheme workable. Oh, and we'd need an interface
> for
> people to add comments, of course.
Well, it's tempting to structure this like the manual at the outset, but
looking over the contributions to the list leaves one with the impression
that the unfiltered comments often span a number of subtopics and are
generally in need of significant editing, which is 'stage 2' of the
process.
I think the purpose of 'stage 1' is to drag useful stuff to the surface
and make it visible, no matter how bloody and unslightly the body
may be, so that it can be cleaned up and made suitable for insertion
into the manual. In this case, big-bin topics might be best.
To the above topic list, maybe we should add 'suggestions for future
enhancements'. Lots of dialogue about this in the archive.
Paul N.
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
