Wiki Coaching

Today, Blue Oxen Associates launched a new Sensemaking Series on Wikis, coached by Peter Kaminski. It’s a fantastic way to get guidance on implementing and integrating Wikis into your organization, which is even more critical these days, given the economy.    (N5T)

I’m particularly pleased that Pete is our coach. Those of you in the Wiki community already know him for his leadership — not just in co-founding the very first Wiki company, Socialtext, but for helping to drive the community overall with his thinking and goodwill. If you’re looking for guidance, you’re not going to find anyone better or more friendly than Pete.    (N5U)

The series starts on May 19. There are only five spots, so register now. Use the discount code “eekim” to get $50 off registration.    (N5V)

Being Ambushed by Terrell Russell

Gail Taylor told me an excellent story last Saturday that reminded me of an incident at the Internet Identity Workshop this past December. I was doing something that I am deeply opposed to — participating in a face-to-face conference without being fully present. Basically, I was sitting in the middle of the space doing work on my laptop while everyone else was participating in the conference. I felt guilty about it, but I wanted to talk to some people while they were in town, and I had a ton of work to do at the same time.    (LWP)

So I gave a talk on Identity Commons, attended a few presentations, talked to a few people, and spent the rest of my time doing my work and ignoring everyone else. It was actually quite nice. I was sitting in the middle of the large conference room at the Computer History Museum, visible to everyone, with people constantly milling around me. People who knew me stopped by to chat for a few minutes; people who didn’t just ignored me.    (LWQ)

Towards the end of the second day, I was basking in my productive anti-socialness, when a fellow who was sitting at my table started making small talk. It was harmless chatter, stuff that I could respond to while remaining focused on my work, but at some point, it felt wrong continuing to talk without introducing myself. Turns out the guy was Terrell Russell of claimID fame. I knew about claimID, but I knew nothing about Terrell. The same could not be said of him, who had known all along who I was, and who apparently follows this blog. (Hi, Terrell!)    (LWR)

That bastard must have used that knowledge against me, sharing ideas that he must have known would suck me into conversation. Either that, or he was just a nice guy who was passionate about his work. Either way, it worked. I ended up closing my laptop and having a great conversation with him.    (LWS)

What was he doing that I found so compelling? It was his Ph.D. research on Contextual Authority Tagging. The basis of the idea is simple: The best way to identify an authority on a topic is not to ask people to self-identify themselves as such, but to ask others to identify the people they consider to be the authorities. We can leverage this principle to locate expertise by building tagging systems where users tag other users with information about their expertise.    (LWT)

Terrell has thought really deeply about this, and several of his ideas are documented at his website and on his blog. Phil Windley and David Weinberger have also commented on his work.    (LWU)

I heard more original ideas about tagging in that 20 minutes of conversation than I’ve ever heard from anyone else. The one that really struck me was the notion of tag disparities: comparing what people say about you to what you say about yourself as a way of measuring reputation. Sound familiar? It’s a real-life instantiation of the Squirm Test!    (LWV)

I think there are some interesting tools that can be built on these ideas, and I have no doubt that Terrell will build them. There are also some face-to-face group exercises based on these same principles, and I’ve actually done one of them before (described below). You could also apply these ideas towards group evaluation.    (LWW)

I’ve been vividly reminded of our conversation on two occasions. The first happened later that week at the Blue Oxen Associates anniversary party. Peter Kaminski decided to do some social engineering of his own, and instead of asking people what they did, he asked them to tell him about someone else attending the party. Real-life, face-to-face, Contextual Authority Tagging! We actually did this for real at the 2005 anniversary party, where we had people literally stick name tags on other people’s back. It was an idea I stole from Chris Messina, who in turn had stolen it from a previous SuperHappyDevHouse gathering.    (LWX)

The second occasion happened this past Saturday. Gail recounted a story about a group exercise with five people, where each person was asked to write ten words that have to do with “love.” Out of the 50 total words, only three were the same! It was a stark lesson on how challenging it is to achieve Shared Understanding and how critically important Shared Language is.    (LWY)

Socialtext 2.0 Released

Congratulations to Ross Mayfield, Peter Kaminski, Adina Levin, and all the excellent folks at Socialtext for the release of Socialtext 2.0. Even bigger props for slipping in “Purple Consulting” in the screencast. I’ve been cranking so hard over the past six months, I didn’t have a chance to congratulate them on their Open Source release last July, so now I get to combine my commentary here. (In fact, I’m sitting on a bunch of Wiki-related posts right now that I need to push out; a lot of really cool stuff has been happening.) That’s good, because I have plenty to say.    (L72)

Socialtext 2.0 is an important release for three reasons. First, it doesn’t just look good, it’s highly usable. Adina and Pete deserve big-time credit for this. They’ve spent months painstakingly experimenting and testing the design. More importantly, they haven’t just focused on making it easy to use, but they’ve also agonized over how to accomodate expert usage as well.    (L73)

Have they succeeded? I think the personal home base concept is great. I love the fact that Backlinks are visible on the page and get lots of love. I love their new Recent Changes interface (and I hope to see a Tag Cloud view of the all pages index in the next release). I hate the fact that a Recent Changes link is not on every Wiki page. Both Pete and Adina are well aware of this beef, and I’m also well aware of their reason for not including it. Testing and user observation will tell what’s better.    (L74)

Second, Socialtext 2.0 has a really cool REST interface. Chris Dent has been boasting about it for months, but I didn’t look at it myself until Kirsten Jones walked me through it last week. (Her WikiWednesday presentation from earlier this month is online.) It really is cool, and it’s also useful. Congrats to Chris, Kirsten, Matthew O’Connor, and Matt Liggett for their excellent work!    (L75)

What’s great about this API is that it could very well serve as a standard URI scheme for all Wikis. This would obviate the need for a separate SOAP or Atom API. You just have a regular Web app, and you get the API behavior for free.    (L76)

For example, Alex Schroeder‘s currently going through the same process that Chris went through a year ago with Atom and OddMuse. An easier way around this problem would be to implement these REST APIs.    (L77)

(This is also a great opportunity for me to mention WikiOhana again, which gained great traction at WikiSym last month and which now has a lively Wiki of its own. PBWiki recently announced its own Wiki API, which is a good thing. We are all part of the same Wiki family. Socialtext and PBWiki need to talk about how their two efforts can work together. That’s the WikiOhana Way.)    (L78)

The third important thing about Socialtext 2.0 is that it’s Open Source. (Big props to Jonas Luster and Andy Lester for finally making this happen.) Here’s the thing. I think the announcement a few months back was overblown by a lot of blogosphere hype. The reality of all corporate Open Source releases is that — in and of themselves — they’re mostly meaningless. Mostly, but not completely. The fact that Socialtext 2.0 is Open Source means that other Wiki implementations can benefit from the great work that the Socialtext developers have done, from the APIs to the user interface. That makes for a healthier ecosystem, which is good for everybody.    (L79)

That said, the reason the actual open sourcing of Socialtext 2.0 (and any proprietary software project) is mostly meaningless is that the license is a critical, but tiny part of what makes Open Source software interesting and important. The big part is the community and collaborative process, and a lot of other things besides an open license are required to make that successful.    (L7A)

Before Socialtext went Open Source, I spent many hours talking to a bunch of people there about the impending release. I wanted to know how committed they were to making this a truly open and collaborative software project, because I felt the potential impact on the Wiki community was enormous. The answer I got was complex. The fact that everyone was willing to talk to me with no strings attached, in and of itself, demonstrated a commitment to openness, and I’m still grateful for that. The code itself will be a short-term bottleneck, as it needs a lot of work before outside developers will find it compelling. I also think the licensing terms are weaker than they need to be, although I also understand the outside pressures that make it so.    (L7B)

In short, I think the spirit is strong within Socialtext to fully realize the potential of this Open Source project, but there are also roadblocks. Hopefully, external pressures won’t squash that spirit. If Socialtext ever fulfills its potential as an Open Source company, it will not only help the ecosystem, but it will also tremendously benefit Socialtext as a business.    (L7C)

Leave A Trail: Stigmergy and Effective Large Group Collaboration

One of the challenges with large group collaboration is keeping track of what others are doing. With a small group, the project manager or group leader can take on the responsibility of keeping others informed. If it’s a single organization, you can theoretically mandate a communication strategy from above, although in reality, this doesn’t work effectively when the organization is large and diverse. For large-scale collaboration between different groups, neither of these are realistic options.    (KCB)

How can large groups communicate most effectively? The answer is stigmergy, a term Chris Dent first introduced to me about four years ago. Stigmergy is a form of indirect communication where organisms react to signs left by others. Ants communicate by stigmergy. They leave a trail of pheremones that other ants pick up and react to. Stigmergy — not centralized command-and-control — is responsible for those amazing anthills.    (KCC)

There is an equivalent pattern in effective large group collaboration: Leave A Trail. I’ve called this pattern Think Out Loud and Visible Pulse in the past, but I like “Leave A Trail” better, because of its association with stigmergy. (Obligatory karma reference: I first heard this name from Peter Kaminski, who in turn credits Chris Messina for explaining it as a principle of Bar Camp.) MGTaylor calls this pattern Ship Product and often describes it in the context of Stuart Kauffman‘s work and patch theory.    (KCD)

The idea is simple. When you work, leave an artifact somewhere where others can find it. An artifact doesn’t have to be comprehensive; in fact, it’s often better when it isn’t. A brief meeting summary is usually more useful than a full transcript. A brief summary with links to specific instances in the transcript is even more useful.    (KCE)

When you Leave A Trail, you’re communicating to whomever wants to listen, which may effect how you express yourself. This can be disconcerting to some. People often point to the lack of response as a sign that tools like online forums, blogs, or Wikis aren’t working. That’s not necessarily the case. There may be a whole slew of lurkers who are reacting to the signs that you are leaving. (That said, Immediate Feedback is also an important pattern in Online Communities.)    (KCF)

This can also be difficult when determining what kind of trail to leave. Because you don’t know who will be reacting to your signs, you can’t target them. The solution is to Scratch Your Own Itch.    (KCG)

Emergence can’t happen without Leave A Trail. However, Leave A Trail is just one of many conditions for emergence. You can’t dictate whether emergence will happen, and when it does, you can’t control what actually emerges. The best you can do is create conditions for emergence and hope that good things happen. This is disconcerting to many, and folks often react by trying to assert more control, which makes things worse.    (KCH)

Leave A Trail and other principles are helpful in designing community spaces. For example, if you are trying to integrate blogs or Wikis into a community’s practice, the best way to do that is to apply the tool in such a way that it scratches an individual’s itch while also leaving a trail. For example, many good project leaders are good at doing meeting summaries. Instead of having them email a small subset of individuals, have them email a public, archived mailing list. Better yet, have them blog their summaries and email links to the blog. You’re not significantly changing individual behavior in these situations, but you are significantly improving your chances for large-scale collaboration.    (KCI)

The Pete Paradox

Peter Kaminski has a great maxim, which those of us who know and love him commonly call The Pete Rule:    (K8N)

“Time together in person is too important to spend working.”  T    (K8O)

I think it’s a great rule, but there’s a corollary, which I’ll call The Pete Paradox:    (K8P)

Time together in person is the best time to work.    (K8Q)

I actually had a specific experience with Peter last October that led me to think about this paradox.    (K8R)

At RecentChangesCamp earlier this month, I faced this paradox first-hand. On the one hand, I didn’t want to waste the opportunity to really get to know some of the excellent folks in the Wiki community who aren’t local to the Bay Area. On the other hand, I had some specific things I wanted to work on — namely SisterSites with Ward Cunningham and other Wiki developers and a YADIS implementation with the good folks at JanRain. Working on these projects meant breaking away from the larger group, popping open the laptop, and focusing on the work at hand.    (K8S)

The paradox resolved itself to my satisfaction. I got both projects done. We implemented SisterSites in PurpleWiki and a bunch of other Wikis, and Brian Ellin and I wrote a YADIS library in Ruby. I met several interesting and cool people for the first time, including Brian, and, I got to know folks like Bayle Shanks a lot better. On the second night, after the conference party, I decided to go to the main ballroom to check my email, even though I was exhausted. The ballroom was empty at first, but about half an hour later, Bayle showed up. We had met at WikiSym, but this was the first time we had a chance to sit down and really talk, and we stayed up past 3am. That was excellent. I had already known that Bayle had done some cool stuff, but it was great to dig deeper into his ideas as well as to talk about non-Wiki stuff.    (K8T)

I even got to discuss The Pete Paradox with Pete in person. (How’s that for meta?!) And here’s how I finally resolved it in my head. Both The Pete Rule and The Pete Paradox are about maximizing engagement. When you are working closely together, you are engaging in a way that is not only more productive, but more meaningful. Face-to-face time spent working can be a waste, but face-to-face time spent truly working together usually isn’t.    (K8U)