New guy offers input on documentation

Well, yeah. But I don’t think MODx will have as heavy a usage as WordPress. By the time it does, we’ll be able to use native MODx features. And there _are_ established ways of making MediaWiki work under heavier usage that WikiMedia use on Wikipedia. Plus, more people have tried MediaWiki in heavy usage situations, so I’m not at all sure that some of the other wikis will be any better.

I believe that using a recognisable wiki enables people to concentrate on MODx rather than be distracted by the unusual wiki software.

I have played with PmWiki and generally I liked it. It is possibly easier to integrate, and is definitely easier to skin. I originally found that when I was looking through some other documentation, although I can’t actually recall what it was.

Hmmm, just an alternative idea; one of the things I’d really like to see considered here is utilization of Trac (which is a wiki). We already have a Trac implementation sitting on our SVN repository. Are there any major drawbacks or missing features in Trac’s wiki implementation that would make it less useful than MediaWiki? My biggest concern is too many user systems, and since I already want to do some MODx-Trac bridge components for this purpose, I think the effort into making this work would be well worth it. Eventually we could offer dedicated SVN and Trac areas (especially if we could afford a dedicated SVN/Trac server; we currently use CVSDUDE) for key components in the repository, manage consolidated committer/team access to the MODx site/SVN/Trac, and generally not have to worry about synchronising all the user accounts across additional systems. In other words, I think the fewer integration points we have to deal with, the better.

I like the theory of integrating more things into one system, but I’ve never personally been knocked out by Trac’s wiki, and I think in this case you really want to hit a home run, usability-wise. Ultimately, the quality and detail of the project’s documentation is going to make a MAJOR difference between success and failure, and you want a wiki with no compromises. Also, who’s to say that you won’t switch from Trac to another bug-tracking solution down the line; better not to be locked into a wiki that’s tied into your bug system.

I’d lob my support for DokuWiki
http://wiki.splitbrain.org/wiki:dokuwiki

Seems a bit lighter weight than MediaWiki yet plenty o’ power.

The forums are definitely not the right place to be storing and organizing information that is documentation-like. Forums are wild and wooly and always end up disorganized, and are not well-suited to storing structured information like documentation. A wiki should be used for documentation and collected knowledge, and the forums should be used as a question-and-answer location, with many of the answers pointing to the correct resource in the wiki.

Great discussion!

Jason or Ryan,

Any progress or update on this? I have been collecting all sorts of notes for a rookie like me and would love to be able to put them into a page for someone. (Just little notes about this or that- it’d solve a lot of faq’s i hope).

No rush...
Chuck

Hmmm... first post because I forgot what username I had previously LOL.

I am one of the team with Mambo Guru, whose wiki was mentioned by Chuck. When I was looking at the various wiki options for our online manual, I went through all the more popular wikis and checked them out. All of them have pros and cons, but for our purposes, mediawiki really stood out from the rest as the most likely to do what I wanted. The wiki had to be solid, with sound development to limit the risk of hacking, it had to easily enable only registered users while preventing unregistered folk from editing, it had to have good search functions, and had to be able to handle a lot of visitors and editors without excessive server loads (we plan for growth )
Security was one of the most important considerations as we anticipated problems.
I also wanted some decent control on the administrative side as I have seen too many wikis get cluttered with author profiles that essentially just promoted the authors and their sites, and have also seen too much good work get defaced by unscrupulous people. DocuWiki was quite good, but not as fully featured as MediaWiki - the others were quickly tested and discarded for various reasons.

Since setting up our MediaWiki, I have been very happy with the choice I made. We are using it purely for documentation but it would lend itself to managing snippets with no problems.

The downside, which applies to all wikis out there, is that although URLs can be rewritten to be very user and search engine friendly, search engines pick up a lot of unneccessary content - things like the author page, edit pages, etc and this can result in search engine penalties.

If you do decided to go with MediaWiki, have a search for the skins done by Robert Castley. I used one as a base for our wiki and it sure saved a lot of time in making the wiki look less "wiki like". Mine is fairly heavily modified, or I would offer it. Robert’s would be easier to work with to make your wiki more integrated with the site look and feel.

Hope this helps.

Thanks for the feedback Elpie.

Is anyone still checking Wikis ?!
I found another good example of wikiDocs on the FckEditor site http://wiki.fckeditor.net/, they’re using http://moinmoin.wikiwikiweb.de/


ciao ciao