Walter,
Now that I'm vaguely caught up from vacation, a few comments:
<< The three issues that immediately come to mind are 1) Establishing and adhering to standards 2) Managing contributions and revisions 3) Managing the (editorial) release cycle >>
You're thinking is more advanced on this than mine is! #1 is a for sure, some thought about this up front would be smart. As for #2 and #3... I think we should start out with a first pass and then see what happens. Since it's somewhat looking like it's just we two for now, I think a less formal process is OK here where it wouldn't be for a software development project. But I've never coordinated on a a group documentation project, so if you have more experience with such things....
<< The two end-user documentation projects that I've had in mind are 1) Module documentation - Perhaps using the existing documentation as a starting point to provide: a) A description of WHAT each module is, what it does, any functional dependencies, one or more examples of how it adds value to a site, etc. b) Instructions on HOW to use it, what's required to implement it (whether or not it's ready to use "out-of-the-box"), how it's administered on an on-going basis, what kind of maintenance is required, etc.>>
"a" seems very urgent and safe... much of the rest may be more dependent on which version is being used. I'm thinking maybe a first pass at "a" and then fill out the rest later.
<< 2) A Glossary of (Open)ACS and possibly other technical terms - Identify and explain terms that an end-user might not have in their vocabulary. It's easy to take for granted that a reader is familiar with a term like "Tcl", and a certain level of knowledge may need to be assumed, but having a place where a reader can go to quickly look up an explanation, placing it in the context of the OpenACS, could greatly extend the accessibility of the documentation.>>
Agreed, would be very helpful. Off the top of my head, I wonder if a glossary might be done 'ad hoc' via the openacs site, ie. (i) people submit terms to be defined, (ii) one or more community members submits responses, (iii) an knowledgeable editor distills the responses and posts an official definition.
< Some redundancy in documentation can also be a good thing, because it's easier to find an answer if it exists in more than one place. >
With documentation, "redundancy" makes me think immediately of maintenance headaches.. but if by redundancy you mean admin documentation separate from user documentation, then YES!!
I'm willing to put in some hours on this work... but my technical knowledge base is pretty shaky, so my contributions are probably best focused on editing, guru interviewing, etc.
We can talk...
