Which kinda leads me to another reason I'm opposed to the plan: it creates a very regrettable precedent.

I think viewing this proposal as "per-group" documentation is the wrong way to go about it. I see it more as a way to keep a complex and cohesive body of documents together. Obviously some group has to have responsibility for maintaining the set of documentation, but that doesn't make it group documentation. Group documentation describes the group itself. If a group had a really complex set of internal policy documents and sub-documents, then maybe it might be a good idea to put them in their own document collection with their own master list containing collection specific strings, documents, doclets, and faqlets. But if not, a wiki would do just fine and I expect the group wouldn't even want more.

Your point about end-users wanting to know technical details of the site is a good one. However, it has more force (to me) as an argument for making the readership open to all monks. It doesn't justify mixing up the documentation into a single pool where all editors have to be members of the SiteDocClan. Even though there are users who want to read technical documentation and pmdevs who want to read end user documentation (of course there are), that doesn't mean that they want the two types of documentation mixed up together.

Perhaps it would help to explain a bit how much documentation there really is? The 20 or so pages in the Everything Bible is misleading. It simply does not give enough information to do anything except make trivial patches to nodes. To really understand the system one needs much more. Just considering the material I've collected so far (or see the need to collect) we have 300+ nodes and quite a few distinct doclists (incidentally there are only 211 sitefaqlets and 247 Perl tutorials). I'd really like to have one master list to keep track of all of the docstrings, doclists, doclets, and faqlets involved in building technical documentation. Here is a sampling:

• data model
  • data model overview
  • one node for each dbtable - 83 nodes
  • doclist containing dbtable documentation nodes
  • one node for each settings node - 63 nodes. Setting nodes define mini embedded databases and the purpose of each attribute (and any associated handlers) needs to be explained.
  • DBMS overview explaining what features we use and why among other things.
  • one node for each supported DBMS - 2 nodes at present (mysql and SQLite)
  • doclist containing DBMS nodes
• node class hierarchy
  • Node class hierarchy overview
  • One node for each nodetype - 100 nodes
  • doclist containing all of the nodetype nodes
  • Nodebase engine overview
  • Database caching overview
• Node display categories for RAT/NN
  • overview of RAT/NN categories
  • overview of the RAT/NN node list generation process, e.g. handle_threaded_nodes.
  • one node for each category - 29 nodes. Each of these comprise a subsystem handle a specific category of content. The node would list the features and explain their implementation, along with any differences from plain vanilla nodes.
  • doclist for RAT category nodes
• display types:
  • display type overview node
  • one node for each display type - 18 or more, it is hard to count because some display types only apply to certain node subgroups
  • a doclist for display type documentation
• PM markup and HTML parsing
• Overview of different categories of markup and where they are used.
• Overview of markup processing
• XML generation ...
• Theme components ...
• Security system and permissions architecture ...
• Where code lives ...
• Patch submission ...
• Bug and enhancement tracking ...
• Mail system interface ...
• Messaging system ...
• Edit history support ...
• Timestamp management ...
• And more ...

Best, beth

Update: added number of sitefaqlets and tutorials for comparison.