The documentation has preceeded the release of the feature. This has only been noticed publically because of changes to Newest Nodes that cause the NN page to display newest FAQ's too. Arguably this is a bad idea, as the documentation's release should be publicized at the proper moment, with an announcement in PerlMonks Discussion rather than at the wrong moment by an automated process.

It is good that the documentation has been prepared prior to the release of the feature, but not good that the documentation is being raised up the flagpoll in Newest Nodes automatically at this early stage.

Of course what I've just written will be mostly nullified when the feature itself rolls out, probably moments before I click "submit". ;) lol

I don't think there's enough of a consensus yet to say for sure that the feature will even be added, much less what exact form it will take, so no need to worry about your stumbit. :)

I didn't realize it would show up; perhaps the proposed/alpha/beta/stable indicator in the SiteDocClan master plan should be in a sitedoc dbtable, and non-stable ones not be shown to non-SDC users on Newest Nodes/Recently Active Threads? Just a thought...

I've now labeled it as describing not yet fully implemented features.

apologies about the stream of consciousness style of this reply...

I think actually a better route might be to create a few new subtypes of the sitefaq. Then NN would only pick up the "published ones". That way places like NN/RAT and supersearch dont have to be taught how to read a special field value, they simply have to have the nodetypes appropriately loaded into the settings. Likewise any node of type beta_sitedoc would automatically have the appropriate caveats about it being a work in progress and may not be and or will never actually turn out to be true.

To do this the existing create new would have to be changed to generate the new subtype and we'd have to have a way to change the nodes type to "publish" them. The FAQ list and friends could be fairly easily implemented by subclassing the nodegroup type and adding the appropriate display overloads. For instance a sitedocgroup would represent a "section" of documents, which can contain sitedocs (of the various types) or other sitedocgroups. Much of this infrastructure is already existant on PM (not sure about the synch state with PMDEV, something that ive been thinking about a lot lately: we need a solution to this problem) and just needs to be exposed. For instance I beleive there is already support for the heirarchical display of nodegroups so that wouldnt need to be coded (and it would be easy even if it Im wrong).

---
s/war/peace/g