Log inRegister

Wiki Facilitation

Preface: I originally posted this expanded meditation on Wiki Facilitation (see my working notes in Lynnwood.WikiFacilitation) or on TWiki:Codev.WikiFacilitation. I've also started to formulate Wiki Facilitation as a "pattern" here. -- LynnwoodBrown

Summary

In this topic, I proposes a new set of "social conventions," referred to here collectively as "WikiFacilitation," for managing WikiConversations in order to enhance and accelerate our group decision-making process.

Why do we need a new approach?

I would like to make a case that for discussions as complex and in a community as open as TWiki.org, we need a more sophisticated approach to facilitating conversations.

Proposition #1: Satisfying and effective discussions have certain inherent structures

Humans have been conversing for a long time. Over countless eons, we have developed certain implicit conversational structures which allow us to make sense of social interactions and derive satisfaction from them. These structures are almost entirely unconscious and, for the most part, only become conscious in their absence. That is to say, we only become aware of them when they aren't working - and the experience is that something is wrong or simply confusing.

The approach presented here does not apply to all possible wiki conversations. The conversations I am addressing specifically are decision-making conversations. That is, conversations in which participants address some challenge or aspiration, identify and evaluate various options for addressing the situation, and, finally, decide on a course of action.

Decision-making conversations have a certain inherent structure that goes through several different stages, each with its own particular dynamic and pitfalls. There are numerous models for this conversational structure but one which I have personally found to be very useful is presented in Facilitator's Guide to Participatory Decision-Making and is what they refer to as the "Diamond of Participitory Decision Making." Basically, this model suggest that groups making decisions go through five main phases:
  1. "Business as usual" leading up to a point where some challenge or opportunity arises requiring a decision.
  2. "Divergent zone" during which multiple possible options are identified.
  3. "Groan zone" in which participants struggle to integrate the various perspectives and options in order to establish a shared frame within which to evaluate the options.
  4. "Convergent zone" in which participants sift out the preferred options.
  5. "Decision zone" in which closure is reached and a course of action is chosen.

Each of these phases have their own dynamics and pitfalls but phases 2 and 3 are particularly prone to problems, resulting in such things as premature jumping to less-than-optimal solutions, failure to move forward, endless meetings, and general frustration for everyone involved.

The main point here is that this basic model in "hard wired" into the human social event we call "decision-making" and while new technologies may contribute to this process, they can not supervene its basic structure.

Proposition #2: What makes wikis great also can make them frustrating

Two features of on-line communication tools in general and wikis in particular that constitute a significant portion of their appeal are "asynchronous communication" and hypertext. There is no doubt about it that these are really cool communication features that open up whole new realms of potential for human communication. The problem is that they can generate conversation that don't reflect natural conversations at all and tend to leave us frustrated. Joel Spolsky makes this point well in in his article Building Communities with Software.

It's my general experience within TWiki.org, that the software tends to favor divergent over convergent aspects of conversations. That is to say, it's easier to give expression to alternative options, or express reservations about prior statements, then it is to give expression to and confirm group support for points of consensus. Referring to the stages of decision-making conversations presented above, I'm suggesting that many discussions can not get "over the hump" to move from phase 2 to phase 4. Even if this predisposition is only slight, it has the effect over time of frustrating the collective ability to reach agreement to how to move forward. I believe there is ample evidence of this on TWiki.org.

Proposition #3: What is needed is a new model of proactive refractoring or "WikiFacilitation"

Based on the above discussion, I would like to propose that certain types of conversations in wikis, specifically decision-making conversations, call for a new approach to interaction and wiki-topic-management that I am calling Wiki Facilitation. Wiki Facilitation could be thought of as a more robust or proactive approach to the current practice of refactoring. My first attempt at a more rigorous definition of Wiki Facilitation is as follows:
WikiFacilitation is using various topic structures and participant input mechanisms to consciously give structure to a discussion, both spatially and temporally, in order to more closely mirror satisfying real-world interactions and to achieve specific group-approved outcomes.

In practice, I see this as mainly involving managing the topic so as to minimize the negative tendencies of asynchronous and hypertext media and thereby preserve factors that make face-to-face conversations satisfying and productive.

Putting it into practice

The practices of Wiki Facilitation

Some of the practices that I envision being applied in Wiki Facilitation include:
  • Defining a clear purpose or intention for a wiki topic. I.e. Clearly stating what we want the discussion to accomplish at the outset and subsequently managing the topic holistically to fulfill that purpose.
  • Anticipate the distinct phases the discussion will need to move through to fulfill the purpose. In practice, this means imposing a temporal order of the discussion that is not inherent in the software. In other words, we would say something like "we are going to brainstorm this question for this long and then complete that phase of the discussion and move on to evaluating the options we've listed."
  • Structure the topic to fulfill each phase and restructure it as the discussion moves to the next phase.
  • Fairly extensive use of structured input mechanisms (i.e. polls, comment boxes, etc) to focus and move the discussion along.
  • Continuous refactoring to distinguish different tracks and levels of the discussion.
  • Maintain stricter "boundaries" of discussion.
    • Isolate "off-topic" threads (as defined by topic purpose)
    • Isolate "out-of-sync" threads - not relevant to current phase of conversation.

Generalized Wiki Facilitation Topic Template

The illustration below is meant to show how a decision-making topic might be structured to support Wiki Facilitation. I find the metaphor of MeatBall:WikiAsRoom helpful in understand how this works. Imagine a room in which a particular proposal is being discussed. The topic structure below is like having a series of different white boards displayed around the walls. On one, displayed right near the door when you come in, there is a summary statement of what the discussion is about. Next to that is another that gives an update on the current status of the discussion. On another wall is several displays of specific items one can vote on or list brainstorming ideas. In another part of the room, there are several small groups discussing specific aspects of the proposal and in one corner is the place where you can comment on anything and everything else going on in the room. The point of this layout is helping everyone keep the overall discussion in focus and anyone to quickly find the most appropriate place to give their input.

TopicPercolation.jpg

Additional References

See also: -- LynnwoodBrown - 11 Jun 2004
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Skyloom Wiki? Send feedback
Syndicate this site RSS

This website is using cookies. More info. That's Fine