Describe Side Bar here.
This page contains Patrick Michaud's comments regarding the "audiences" for which Pm Wiki was designed. As such, many people are reluctant to modify the page, because it is a statement of his opinions and describes some of the thought that went into creating Pm Wiki. (And we all thank him for that!)
I think of Pm Wiki in terms of two audiences: Authors are the people who generate web content using Pm Wiki, and wiki administrators are the folks who install, configure, and maintain a Pm Wiki installation on a web server. In some senses it could be claimed that as the primary developer of Pm Wiki I should only have wiki administrators as my target audience, and that authors are the target audience for the administrators. But what really makes Pm Wiki useful to wiki administrators is that I've put a lot of consideration into creating a tool that is usable by authors, so I have to keep the needs of both audiences in mind as I'm designing and adding new features to Pm Wiki.
Within the authoring audience I see that there are "naive authors" and "experienced authors". "Naive authors" are the folks who use wiki to generate content but may know next-to-nothing about HTML, much less style sheets or PHP or the like. Naive authors are easily discouraged from generating web content if they have to wade through markup text that has lots of funny and cryptic symbols in them. So, if we want a site with lots of contributors, we have to be very careful not to do things that will cause this group to exclude themselves from participating.
"Experienced authors" are the folks who know a lot about HTML and could write their content as HTML, but have chosen to use wiki because of its other useful features (ease of linking, collaboration, ease of updates, revision histories, etc.) or because they want to collaborate with naive authors. Experienced authors usually don't have any problem with documents with lots of ugly markup in them; after all, they already know HTML. Experienced authors are sometimes frustrated with wiki because it doesn't have markup that would let them do something they know they can do in HTML (e.g., tables, stylesheets, colored text, etc.). And, they sometimes have difficulty understanding why naive authors would turn away from documents that have lots of markup sequences in them.
For the wiki administrator audience--the folks who install and may want to customize Pm Wiki--their backgrounds and goals are often quite diverse. Pm Wiki is designed so that it can be installed and be useful with minimal HTML/PHP knowledge, but it doesn't restrict people who know HTML/PHP from doing some fairly complex things. For one, Pm Wiki allows a site administrator to build-in markup sequences and features customized to his/her needs (and the needs of his/her audiences).
The separate needs of these audiences are behind most of the PmWikiPhilosophies. The people who develop Pm Wiki software must continually keep naive authors in mind as new features are requested and proposed by expert authors and Wiki Administrators. Sometimes it may seem to these latter groups that it's okay to implement the complex features because "naive authors don't have to use them", but the truth is that if complex/ugly markup sequences are available then they will eventually be used by someone, and once used they become a barrier to the naive authors. So, if I see that a feature could become a barrier to a naive author I don't include it in the base implementation of Pm Wiki, but instead find ways to let Wiki Administrators include it as a local customization.