> I'd argue that dev documentation changes far more frequently than the UI-design which has to be documented through userhelp. You can also expose devs to a bit more "fluidity" than end-users, hence the wiki approach.
Ok, I partially agree with this.
> Thats not to say that we can't change dev documentation to be cms powered, but that would require some architectural changes (separating module-documentation and tutorial-contributions from core API documentation).
As I heard you just recently choose MediaWiki for your new dev doc backed and done some work around it. So I think now one will want to bother with this idea.
> Ideally there's at least one "owner" of userhelp which keeps an eye on the changes, and a smallish group of frequent contributors. This group can pick up corrections/suggestions from the user comments. Typical too many cooks in the kitchen problem I guess. If you leave userhelp edits open to everybody, you get a dozen different writing styles, duplicate content, unreviewed incorrect information, etc.
This is a good idea to get the user help outdated as it got now.
Face it: there won't be any group constantly working on the user help.
I agree to make publication-approval mechanisms reserved for the user help "owner" so that no trash content will be showed to end users. But please let the people work on the user help when they what to and without having do ask you for permission to help you.
Resuming. OK keeping SS as the back end of the user help i also an good idea. A just got the info from the SS team that it got ported to 2.3 which is another plus for it. But as from my point of view the registration of editors in the user help has to be open.