The major premise of this book is that expectations for documentation have shifted from bookshelf to search. This means your documentation is no longer the sole, authoritative source of information, and people won't go through it in your intended sequence.
Instead, you need to update frequently to stay at the top of search results, invite the community to interact with you and their peers, and use the results of that interaction to inform further development of the documentation.
The book includes a good reference guide to the major concepts and tools that technical writers might consider using. Anne's use of terms like syndicated content in place of more technically specific terms like RSS reinforces the theme of thinking abstractly about uses before getting caught up in the nuances and details of specific technologies.
Regarding wikis, examples in the book focus on public-facing sites like wikiHow, the World of Warcraft Wiki, Adobe Labs, Apache, and SugarCRM. This makes sense in the context of sharing documentation with a community, but it's also important to keep in mind that external audiences shouldn't always have the ability to directly edit the contents of wiki pages.
The commenting or threaded discussion capability on wiki pages can be a more useful means of interaction because it reduces the risk associated with making content editable by anyone, and it can focus peoples' interaction on asking questions, getting clarifications, and suggesting improvements.
The book spends a considerable amount of time defining the roles that technical writers can play in a community participating in the development of documentation. Anne suggests that there are two distinct roles for technical writers: Sage on the Stage (instigator of conversation), and Stagehand (enabler of conversation)
An instigator, she says, can spark activity by introducing a hotly debated topic or decision and soliciting feedback. Where the instigator draws out responses from the community, an enabler of conversation makes sure that enough information is available to community members so they can offer authoritative, informed responses to issues and questions raised by others.
Whether playing the role of instigator or enabler, Anne says technical writers must listen to the conversation to bring ideas, requests, and needs into the process of refining and updating documentation. These two factors - high quality information and a high level of discourse - establish the community as a worthwhile, useful place to interact, and encourage people to come back when they need new information.
This section of the book reminded me of ongoing conversations in higher education instructional design and educational technology circles about the shifting role of the college professor or teacher from "sage on the stage" to "guide at the side". Curriculum development and technical writing are certainly similar in that both aim to develop materials that teach people how to do something well, and both can benefit from involving the learner in the ongoing refinement and evolution of those materials.
The role for technical writers is expanding into one that can involve significant community interaction and management in addition to simple producing documentation. To be clear, not all technical writers will want to do this, and in large communities a dedicated community manager may be a better option. However, those technical writers that directly manage communities or work closely with community managers have an opportunity to tap into a rich resource.
An engaged community can guide the evolution of documentation into a resource that goes far beyond the traditional notion of bookshelf documentation or "guides for dummies". This is the era of guides for smart, discriminating, highly engaged people who place high value on information that they can both use and help to evolve. Conversation and Community is an excellent guide to making the most of this opportunity.