Dear Russ, > The second approach sounds like more of a slam than living in > a 'projects.' sub-domain to me. > > A refactoring of the personal homepages will have to happen in > any event, and perhaps we should simply have a './personal/' > in the main wiki and move all such into it ... but this then > carries the expense of refactoring all the 'at the ./' point > documentary narrative down a level as well. ACL errors will > be harder to avoid as well > > By carrying two wiki, we avoid that workload, and can have a > self-serve model for getting commits in the 'projects.' one, > and the moderated approach on the vetted one. Which means that there will possibly more than one documentation per task, e.g. there could be a KVM tutorial in the moderated and one in the 'open' wiki space. If the quality of an article in the 'open' wiki is good enough, who ports/merges it to the moderated one? Sounds quite odd to me, sorry. But I agree that the content of the current CMS/XOOPS and parts of the wiki could also be handled through the wiki with strict ACLs. Maybe centos.org could link to these sites and centos.org/contrib could act as place for user/developer contributed documentation which then should be as open as possible. Access to the contrib sites should be granted after agreeing to the CC license, without the need to discuss changes/contributions on the ML. We could add a disclaimer to the contrib pages, too. Best Regards Marcus