Battling Group Think

Geoff Cohen asked:    (PM)

As we build different kinds of groupware/social software, what’s the role of consensus, and how powerful is it? Does software make reaching consensus easier or harder? For purely message-driven systems like email lists or USENET, consensus is much harder to reach than it would be in a real-life meeting. But once consensus is reached, breaking that consensus often brings down the flames of wrath. All of this is somehow invisibly coded in the interstices of the software architecture and human nature.    (PN)

…    (PO)

Could we architect social software that fought groupthink? Or does it just make the gravitational attraction of consensus, even flawed consensus, ever so much more irresistable?    (PP)

Seb Paquet responded:    (PQ)

I think the key to avoiding unhealthy levels of groupthink has to do with designing spaces that consistently exert pull upon outsiders (or social hackers or community straddlers), so as to keep the air fresh.    (PR)

…    (PS)

I think the blogosphere exhibits this kind of “outsider pull” much more than topic-focused forums.    (PT)

…    (PU)

But what about action? A diverse group has fewer blind spots, but on the other hand, agreement in such a group can be harder to establish, so there is a real possibility that the group will go nowhere beyond conversation. Is a core of agreed-upon ideas necessary for group action to take place? I think so. Does this mean that group action requires groupthink? Not necessarily, because some people are able to act upon ideas without believing in them so strongly they can no longer challenge them.    (PV)

Ross Mayfield added:    (PW)

He [Seb] is right that groupthink is avoided by a social network structure that allows a dynamic and diverse periphery to provide new ideas, but the core of the network needs to be tightly bound to be able to take action.    (PX)

That’s the main point of Building Sustainable Communities through Network Building by Valdis Krebs and June Holley.    (PY)

…    (PZ)

The ideal core/periphery structure affords a densely linked core and a dynamic periphery. One pattern for social software that supports this is an intimacy gradient (privacy/openness), to allow the core some privacy for backchanneling. But this requires ridiculously easy group forming, as the more hardened the space the more hard-nosed its occupants become.    (Q0)

Finally, Bill Seitz commented:    (Q1)

I think a shared mission is necessary. Whether that amounts to groupthink is a fair question.    (Q2)

There are a goldmine of ideas here, and the discussion is highly relevant to issues currently faced by the Collaboration Collaboratory. I’ll address them one at a time.    (Q3)

Group Think Versus Group Action    (Q4)

Bill’s comment points to the crux of the matter. What qualifies as Group Think or Group Action? We’ve discussed this question a lot at Blue Oxen Associates. In our upcoming research report, we draw a distinction between bounded and unbounded goals, and individual and collective goals. Generally, having shared unbounded goals is enough to constitute group alignment, but having shared bounded goals is required before you can call an effort “collaboration.”    (Q5)

The larger the group, the harder it is to define a shared, bounded goal that every group member will endorse. A good example of where this happens are elections. In the case of Howard Dean supporters, for example, the community is defined by a universally shared, bounded goal — voting Dean for president in 2004. As we’ve seen in the Dean case, having that universally shared, bounded goal was a galvanizing force for a previously unseen community of progressives in this country.    (Q6)

For large groups, I don’t think it’s necessary to have universally shared, bounded goals, although it’s nice when it happens. It’s enough to have small subgroups sharing different bounded goals, as long as they do not conflict with the unbounded goals, which must be universally shared.    (Q7)

The Intimacy Gradient Pattern    (Q8)

An aside on terminology: Intimacy Gradient is an excellent name for the phenomenon I first tried to describe in a previous blog entry, where I introduced the Think Out Loud and Whine In Private patterns. The problem I had in describing the Whine In Private pattern was that some spaces — blogs being the best example — felt like private forums, but were actually public. So people whining on their blogs are not actually Whining In Private; they just feel like they are.    (Q9)

Ross also used the term Backchannel, which I had also recently noted in my Wiki as a good name to describe this mostly private, but partially public space.    (QA)

Community Boundaries    (QB)

One of the founding principles of the Blue Oxen Collaboratories is that the products of the discussion and interaction should all be freely available to everyone. This is why the mailing list archives are publically available, even if participation is restricted to members.    (QC)

There is an Intimacy Gradient pattern involved here. There is a small barrier to entry to participate in tight-knit discussions, which makes the environment more conducive to parlor-style conversations. On the other hand, anyone can benefit from the resulting knowledge, which is our ultimate goal. Our hope is that the collaboratories act as a substrate for a much larger conversation.    (QD)

This has already begun to happen, and blogs play a key role. Bill Seitz, Chris Dent, Danny Ayers, and I have all blogged about discussions on the Collaboration Collaboratory, which expands the conversation to a larger group. The side effects include countering Group Think, as Seb suggests, and also attracting new members who want to participate more directly in the lower-level interactions. Similarly, we mention these blogs on the mailing lists, so the collaboratory members are aware of the larger conversation, thus completing the circle.    (QE)

Are there hidden costs to these Intimacy Gradients? Absolutely. Examples of blogs being read by the “wrong” audiences abound. Gregory Rawlins became a victim when he made some choice comments about another programmer’s software on a private, but publically archived list. (Sorry, Greg, but I always get a good laugh when I reread this.)    (QF)

Nevertheless, I think the benefits outweigh the downsides. I recently joined Howard Rheingold‘s Brainstorms community, and have wanted to link to some of the discussions there, but couldn’t. It’s unfortunate, because those linkages are lost, but it’s a tradeoff I understand. Finding the right balance is tricky.    (QG)

How Open Should Wikis Be?    (QH)

Our original intention with the Wikis on the Blue Oxen Collaboratories was to treat them the same as the mailing lists — restrict writing to members, but allow anyone to read the content. However, we did not configure our Wikis that way, mainly because we couldn’t — UseModWiki doesn’t have this feature — and it was low on list of things to hack. (See PurpleWiki:RoadMap.)    (QI)

Based on our experiences with this configuration and further examination of other Wikis, I’m reluctant to change this model now. One potential compromise is to require registration to write to the Wikis, but to make registration free. The difference between this and simply allowing anyone to click on “Edit This” is subtle, but significant. I’m still a bit undecided on this issue, although I seem to be leaning in favor of extreme openness. The reason for this is simply that we’ve had some interesting contributions and comments to the Wikis that probably would not have been made if there were even the slightest barriers to entry. Again, it’s a good safeguard against Group Think.    (QJ)

This issue recently cropped up again, because both the PurpleWiki and Collaboration Collaboratory Wikis were vandalized for the first time. Chris Dent discovered the act first and quickly fixed it, noting, “In a way this is sort of a good sign. Infamy is almost as good as fame….” My reaction was, “Good catch, by the way. A good sign of a healthy Wiki is how quickly the community fixes vandalism.” Notable in both of our reactions was that we simply fixed the problem and moved on, instead of rushing to implement access control.    (QK)

John Sechrest, however, suggested that access control was exactly what the Wikis needed, which led to some interesting philosophical debate about the openness of Wikis. My response to John wasn’t very deep, but it does sum up my feelings on the matter: “Wikis are successful because the cost to contribute are zero. There are downsides, but there are also upsides. Get rid of one, you also lose the other.”    (QL)

WikiWhiteboard

Many moons ago, Danny Ayers reported the successful prototype of WikiWhiteboard, a simple tool for creating editable SVG images on Wikis. Motivated by the simplicity of the design and a little subtle prodding by Danny, I ported it to PurpleWiki. (See PurpleWiki:WikiWhiteboard.) Danny’s writeup on WikiWhiteboard, “Creating an SVG Wiki”, appeared last month at XML.com.    (K4)

The WikiWhiteboard code will be released in the next version of PurpleWiki, although I will be happy to release code early to anyone interested.    (K5)

perlIBIS: The Virtue of Thinking Out Loud

Read Danny Ayers‘s blog this morning, and saw an entry describing Ken MacLeod‘s recent experiment with IBIS Dialogue Mapping. I took a look, and was surprised and thrilled at what I saw. Ken had used (and improved) perlIBIS, which I had written and last released two years ago.    (JU)

I note this not just because I’m pleased (I am), but because it also shows the importance of knowledge capture and thinking out loud. I had announced this work to members of the small Dialogue Mapping community, and had received some positive feedback but little else. That was fine; my motivation in writing the tool was to Scratch Your Own Itch and experiment with some ideas, and I accomplished that. That said, it was gratifying to see that the ideas and the tool had propagated outside of that community, and that someone else was doing something valuable with it.    (JV)

Perhaps this will be the kick in the pants I need to finally write up some of my notes on Dialogue Mapping, both for synchronous and asynchronous collaboration.    (JW)

Revising Blog Entries

Ross Mayfield observes that, when there are sudden news events, bloggers continually revise the same post rather than make new post after new post. He notes that this is very Wiki-like behavior and is not how blogs are supposed to be used, citing Dave Winer’s essay, “What Makes a Weblog A Weblog?”.    (7U)

This all goes back to Danny Ayers‘s recent question about dynamic content in Wiki pages, and my subsequent response.    (7V)

Purple Numbers and Link Integrity

Danny Ayers is looking to implement Purple Numbers in his Wiki, and had the following question:    (66)

But is the expectation that the anchor will always refer to the same information item?    (67)

If we’re going for coolness, I think this may cause problems in the context of Wikis. Ok, pages come and go but the URI will (usually) always address something sensible – edit new page if the one originally addressed has gone.    (68)

But the Purple anchors are pointing to info-snippets that may be modified (no problem – it’s still conceptualy the same item) or be deleted (problem).    (69)

The expectation is that the information to which an anchor points may change. This is obviously not ideal.    (6A)

In March 2001, I wrote some notes for the Open Hyperdocument System entitled, “Thoughts on Link Integrity.” I had posted those notes to a mailing list, but those archives no longer exist, so I reproduce those thoughts below.    (6B)

Danny also mentioned using trackback as an aggregator of comments. There is such a system, which Chris Dent also mentions in his response: Internet Topic Exchange. We used it for the 2003 PlaNetwork Conference to aggregate blogs about the conference.    (6C)

Thoughts on Link Integrity    (6D)

We want the OHS to maintain link integrity across all documents. In other words, once you create a link to something, it should never break.    (6E)

The first requirement for link integrity is that documents are never deleted from the system. If you link to a document, and that document is subsequently removed, the link breaks. The only way to fix that link is to put the document back into the system.    (6F)

The second requirement is to have a logical naming scheme that is separate from the physical name and location of a document. On the web, if you have the document http://foo.com/bar.html, and you move it to http://foo.com/new/bar.html, links to the first URL break. You need a name for that document that will always point to the right place, even if the document is physically moved to a different part of the system.    (6G)

The third requirement is version control. This is where things start to get a little hairy. Version controlled systems are insert-only. In theory, nothing is ever removed. This satisfies the first requirement.    (6H)

However, in a useful DKR, links don’t just not break, they also evolve. Suppose you have a document, foo.txt, that contains the following text:    (6I)

  These are the dasy that try men's souls.    (6J)
  Example. foo.txt, version 1.    (6K)

Note that there’s a typo — “dasy” should be “days.”    (6L)

Now suppose someone creates a link to this sentence in this version of the document. Suppose that afterwards, you notice the typo and correct it. This results in a new version of the document:    (6M)

  These are the days that try men's souls.    (6N)
  Example. foo.txt, version 2.    (6O)

If your links neither broke nor evolved, then the original link would continue to point to version 1 of the document, not this new version. However, this does not always seem to be desirable behavior. If I created a link to this sentence — essentially designating it interesting and relevant content — when the typo is corrected, I’d prefer that the link now point to the corrected document, version 2.    (6P)

This is certainly doable. The system could automatically assume that the link pointing to the first sentence in version 1 should now point to the first sentence in version 2.    (6Q)

However, there are two scenarios when this would not be the correct behavior. First, what if, instead of fixing the typo, the sentence was changed to:    (6R)

  Livin' la vida loca.    (6S)
  Example. foo.txt, version 3.    (6T)

If the purpose of the link is to designate the target content as relevant, then the content of the first sentence of this third version no longer applies, because the meaning of the sentence has completely reversed.    (6U)

Second, what if the link is from an annotation that says, “There’s a typo in this sentence”? In this case, you would want the link to point only to version 1, since the typo does not exist in version 2 (and, for that matter, in version 3).    (6V)

How can we accomodate these scenarios? One solution would be to allow the user to define how the link should evolve with new versions of the document. So, for example, you could specify that the link that points to the first sentence in version 1 should also point to the first sentence in some number of subsequent versions of foo.txt.    (6W)

Another solution would be to have the system automatically notify everyone who has linked to a document (or who has otherwise registered for notification) that the document has changed, and have those people manually update their links, possibly providing suggestions as to how to update the links.    (6X)