Wiki Patterns

I think Camel Case is a feature, not a wiki pattern / anti-pattern, so I don't see how it belongs under this subject.  Besides,  as originally written, especially the conclusion  "these wikis should be avoided" is strongly judgmental.

I'd consider Free Linking by default to be the anti-pattern because it tends not to lead to Accidental Linking.  The readability of CamelCase links is very easily addressed by displaying CamelCase links with spaces and having a simple way to escape words that are not supposed to be links.

I also think that there are strong positive benefits to CamelCase. These might not accrue to certain groups/wikis, but the more you have a group trying to actually get something done, the more that growing a SharedVocabulary becomes necessary and helpful. http://webseitz.fluxent.com/wiki/LinkAsYouThink

I'd like to suggest making this page into a pattern page, instead of an anti-pattern. Zoli makes a good point about whether this is just a feature or really a pattern and while I'm not sure there's one right answer here, I like Bill's comment about the benefits of a common language for members of a community.
What do you think about moving it, and centering the content around the idea of common language? We could include a caveat about it potentially being confusing, and explain the meaning behind it...

Cheers to that Stewart, Bill hits it right on the head. [CamelCase] as a wiki pratice is a good thing in many cases, just not for an encyclopedia. [MarkDilley]

I think the meta-issue here is that different Patterns apply in different contexts. http://webseitz.fluxent.com/wiki/WikiTypes

As for the example of LinkedIn automatically becoming a link, good, it should, it is a RealName issue. I think it is beneficial to the reader to click on LinkedIn and find out what the heck it is. Having names linked automatically is one of the best reasons for CamelCase, imho. Best, MarkDilley

Bill makes a good point about context which needs to be addressed so the pattern language can be pluralistic. I'm thinking that the template for a pattern could include a section called Context in which we describe in which types of wikis the pattern applies or doesn't, and perhaps also a section in which the arguments for and against the adoption of a pattern can be listed.

We used a CamelCase wiki and often ran into issues where acryonyms and names (i.e., business entities or products) with many capital letters would be automatically linked, when users didn't want it to be linked. This required using the "do not create wikiword" syntax, which made things more confusing for the users. It seems to have increased confusion and annoyance with using the wiki.

Many users I've worked with do not like camel case for some of the reasons stated above.  I don't either.  When I'm creating a page I'm very conscious of the things that I would like to have as links or future links, and am happy to use square brackets or some other quick shortcut.  There are lots of things that are naturally camel case (say, database table names), and if there's no intention to create entries for every single one, seeing all those red "potential links" as I read a page drives me nuts.   Then again, for me that's a short drive

The most powerful point in support of the CamelCase pattern is that the pattern allows people to come back and define the deep-dive later, and not have to go through dozens of Wiki pages to manually link the topic. 

Case in point - if you're doing systems documentation in a service oriented environment, you may be documenting systems or use cases on the 'higher level' systems that reference discrete services or operations on services.  You may not have the services documented yet -- but as you create all the documentation, the CamelCase link pattern allows you to go back and define the services as they're defined (organically) if they're new, and voila -- your documentation now links to live topics that allow full traceability...

I think it is a must have. Bill's point about encouraging a SharedVocabulary is a great one.  There's significant secondary benefits to that when people start speaking in the same language and referring to things the same way.