And if we're going to make a new nodetype, whose functionality is separate from the existing sitedoclet, we have the freedom to design it so that it really meets our needs, rather than feel conceptually constrained by our ideas of sitedoclet. Among other things, we could use hard linking to associate the doc and its referent, rather than the "symlinking" currently used with sitedoclets.

To do that right, we have to understand what our needs are. How do we want this thing to work? The first question, to my mind, is: Should it be a single authoritative "document" which authorized users can update, or do we want threaded discussion?

I believe that we definitely do not want the latter, though it would be fun to implement. We could use note, which is the essential node for threading, and we could set the parent/root pointers to the referent node (the one being documented). In our case, we'd probably want to use pmdevnote, as it is identical to note except for who's authorized to access them. These are already being used for threads spawned under patches.

One nodetype which is a hybrid of the two approaches is categorized answer. The main document would be a "static", updatable node, with a pointer back to its referent; and discussion could spawn below it as necessary.

Just about any editable node can be made editable by a group simply by giving node ownership to the group.

wiki is a nodetype specifically designed to support growing content and collaborative editing. It does not have parent/root pointers, however.

In some of these cases, we'd want to clone the existing type to a new type; in other cases, we could use the existing type as is.

Bottom line - It looks like sitedoclet is probably as good a starting point as any. :-)

So, what, if any, are the downsides of basing it on sitedoclet? For one, we'll probably have to continue the title-based implicit linking scheme — assuming we don't want to add fields, which would necessitate creating a new db table — which I think we'd prefer to avoid, if possible. But note that this constraint pertains with any nodetype not derived from note.

Which makes me think... Maybe we start with pmdevnote, since it has the fields we want, and simply customize its code to be like that of sitedoclet. And we'd add in some of the growth/collaboration support from wiki code. Yes. This is probably the way to go. :-)

The "symbolic linking" scheme isn't particularly bad, however: the relevant node titles are generally static and unique. The exception (on the second point) is patches, but we don't want to do this with patches anyway, I don't think. Those support threaded discussions already.