In this topic, I proposes a new set of "social conventions," referred to here collectively as "WikiFacilitation," for managing some topics on TWiki.org in order to enhance and accelerate our group decision-making process. In other words, this is about getting the TWikiTrain
moving on down the tracks to fulfilling its destiny!
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 (WN) 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:
- "Business as usual" leading up to a point where some challenge or opportunity arises requiring a decision.
- "Divergent zone" during which multiple possible options are identified.
- "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.
- "Convergent zone" in which participants sift out the preferred options.
- "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
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 WikiFacilitation
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 WikiFacilitation
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
Some of the practices that I envision being applied in WikiFacilitation
- 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.
The illustration below is meant to show how a decision-making topic might be structured to support WikiFacilitation
. 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.
Comments and Discussion
Nice work LynnwoodBrown
. I'll comment more when I've finished reading my copy of Facilitator's Guide to Participatory Decision-Making
- 03 Nov 2004
discussed the "evolution" from a topic with a lot of discussion into a "final document" that synthesizes the content.
There are a lot of instances in Codev where topics stay in Wiki:ThreadMode
for too long, and any good idea or content is lost. Or worse, good content remains scattered among topics.
I think that WikiFacilitation
is a step towards fixing that, so every discussion ends up as something useful.
- 03 Nov 2004
is more than just refactoring from Wiki:ThreadMode
It's a way of allowing ongoing discussion of divergent viewpoints without having to wait for a consensus before refactoring into DocumentMode
, which allows the divergent ideas to be more fully explored and understood, therefore increasing the likelyhood of the topic reaching a consensus and being refactored into DocumentMode
- 04 Nov 2004
Refactored out BayleShanks
's question to OnlineDeliberationConference2005
- 28 Feb 2005