Gail Taylor – Page 4 – Eugene Eric Kim

Red and Yellow Threads

Published January 1, 2005 by Eugene Eric Kim

Gail Taylor likes to talk about the need for The Red Thread and Yellow Threads in groups. The Red Thread is a concept from filmmaking. It’s the tie that binds, an element found in every aspect of a project that helps create a unified whole. Alicia Bramlett, an artist and filmmaker who often works with MGTaylor, has written a beautiful description of The Red Thread and its role in filmmaking. (GFZ)

Gail first described Yellow Threads to me a few weeks ago as we were discussing the participants of an upcoming Blue Oxen Associates event. If you look carefully, you will find Yellow Threads woven throughout oriental carpets. They themselves are not apparent, but their presence makes the surrounding colors more vivid. (GG0)

Wikis And Face-To-Face Events

Published August 2, 2004 by Eugene Eric Kim

Face-to-face gatherings are very good at generating a large amount of enthusiasm and momentum. Unfortunately, that energy usually dissipates soon afterwards. (204)

Here’s what generally happens: Folks leave the event exhilirated, but exhausted, and return only to discover a daunting pile of work. By the time they’ve made their pile manageable, the only artifact of their gathering is a lingering feeling of, “Oh yeah, that was fun.” The work that was done and the work that was to be done is mostly forgotten. (205)

For the past two years, I’ve been designing a set of processes that use online tools to maintain and even increase that energy after an event. I’ve had the opportunity to experiment with bits and pieces of the methodology at the past two Planetwork conferences and the recent AdvocacyDev convergence to varying degrees of success. At the MGTaylor 7-Domains Workshop last month, I finally had a chance to test the methodology in its purest form, and I was extremely pleased with the results. (206)

The Process (207)

The process is based on two principles: (208)

The event itself must result in a living Group Memory, not just an event memory. (209)
Participants must be literate in the tools used to collaborate afterwards. Otherwise, the tools become an impediment. (20A)

The process addresses both of these principles simultaneously by using the online tools for developing that Group Memory during the event itself. This gives people — especially non-techies — the opportunity to orient themselves around the tool in a comfortable environment. The better integrated the tool is into the event process, the more accelerated the learning. (20B)

What makes a Group Memory alive? (20C)

Group ownership. The problem with after-the-fact proceedings or journals is that participants aren’t necessarily invested in the results. Hence, they’re likely to ignore them. How many participants read event proceedings after the fact? One corrollary to this is that Group Memory does not have to be polished. A rough diagram developed by the group as it worked is more valuable than an edited summary of the event written by a third-party observer and published several days afterwards. (20D)
Dynamic. You have to be able to add to a repository and refactor existing content. (20E)

Tools (20F)

Wikis are an outstanding tool for Group Memory. However, simply making the tool available during an event will not automatically result in Group Memory. The end product of Wikis at most conferences is not usually representative of the attendees at large. The main reason for this is that the percentage of participants who use them is usually fairly low. (20G)

Wikis also tend to be underutilized because they are advertised as conference space and not community space. Organizers don’t expect them to be living spaces for continuous discussion and collaboration, and hence, they aren’t. (20H)

(A quick aside on Mailing Lists and Group Memory. Contrary to what one might think, Mailing Lists can be very effective as a Group Memory. It’s possible to refactor existing discussions by posting summaries, a common practice in many effective online communities. However, Mailing Lists alone tend to be much more useful for participants as a Knowledge Repository than for outsiders. I think Mailing Lists are far more powerful as a complement to other tools, such as Wikis.) (20I)

7-Domains Workshop (20J)

I always felt that the best people with which to do this experiment were the good folks at MGTaylor, because their events: (20K)

Are action-oriented and highly interactive. (20L)
Consist of large, eclectic crowds, often technological newbies. (20M)
Emphasize face-to-face, multimodal interaction. This presents interesting design challenges, because they usually discourage laptops at their events. (20N)
Place great importance in documentation and assembling knowledge. (20O)

How did this differ from some of the previous events Blue Oxen Associates has worked? (20P)

There were many non-techies at Planetwork, and the Inter Active sessions took center stage. However, despite Jim Fournier and Elizabeth Thompson‘s best efforts, Planetwork was still a talking-heads conference (and a good one at that). Planetwork gets a special mention, though, because that’s where I first met and worked with Gail Taylor. (20Q)
AdvocacyDev was highly interactive, it was fairly large (40 people), and the Wiki played a central role in the design. However, the group was already very familiar with Wikis, and those who weren’t were technical enough and motivated enough to figure them out quickly. (20R)

The 7-Domains Workshop is a semiregular gathering of the folks in the MGTaylor network, practitioners of the process. There were about 60 participants representing a number of organizations, including Vanderbilt Center For Better Health (our host), Cap Gemini, and the VA. The purpose of the gathering was self-evaluation and collaboration on improving both individually and collectively. (20S)

My primary role was to help integrate the Wiki into the design of the event and to support Wiki usage during the event. I also assisted in other Krew duties. In addition to being a somewhat ideal audience for my experiment, I had a few other advantages: (20T)

By nature, the participants were interested in collaboration, experimentation, and learning. (20U)
Most of the participants owned and brought (at the urging of the organizers) laptops. The center had wireless ethernet, ethernet jacks, and several kiosks for those who did not have computers. (20V)
We had outstanding facilitators and a great Krew. These folks quickly oriented themselves to Wikis before the workshop and naturally assumed the roles of Wiki gardeners during. (20W)

Workshop Design (20X)

I played a very small role in the design of the event itself. Of the four facilitators — Matt Taylor, Gail Taylor, Rob Evans, and Bryan Coffman — Matt and Gail understood Wikis quite well. In fact, their conceptual understanding of Wikis was much more advanced than their proficiency with the tool, which I think is quite unusual and impressive. They had insights into the tool’s potential that many people who are quite skillful with the tool never see. Gail had also worked with me at both Planetwork conferences, so she had some experience with what did and did not work. (20Y)

On Gail’s suggestion, the primary group exercise at the event was to write a book. The exact topic and format was not specified — that would evolve as the workshop unfolded. The only thing that was understood was that everybody would participate — participants, facilitators, and Krew. (20Z)

The book exercise solved many problems. Like most MGTaylor events, it built knowledge assembly into the workshop process. More importantly, it made the participants responsible for that assembly, which kept them invested in the content. Traditionally, the Krew is responsible for documenting the event and assembling that knowledge afterwards into a journal. At this event, the participants documented the workshop themselves using the Wiki. This not only sliced two days off of the Krew‘s normal responsibilities, it also freed them up to take more of an assembler role, and it allowed both Krew and facilitators to contribute to the discussion in ways not previously possible. (210)

There was no training. On the second day of the five day workshop, I spent about forty-five minutes talking to the entire group about the philosophical underpinnings of Wikis and about ten minutes demonstrating the Wiki itself. With other groups, I would have skipped the philosophical discussion entirely. Beyond that and a one-page Wiki formatting cheat-sheet, there was no training. I was on-hand to help, as were the Krew and facilitators, and participants were encouraged to help each other. (211)

As an initial exercise, we precreated pages for every participant. We then asked people to add some information about themselves, then to go through the Wiki and comment on another page that interested them. Having people write in their own pages allowed us to avoid a massive edit conflict problem. It also gave people a fallback if they were unsure of where to add content, and it populated the Wiki with a lot of useful and interesting information. People are social animals. We like to read about other people. (212)

The Results (213)

As expected, a bunch of people were skeptical about the Wiki at first. By the end of the week, the Wiki had over 400 pages of rich and interesting content, and a month later, people are still using it. Several people gushed about the tool — Holly Meyers, one of the Krew, loved it so much, she wrote a manifesto entitled, “Wonderful Wiki.” Many asked me afterwards about setting up Wikis in their own organizations. (214)

The “book” synthesized a lot of group knowledge, which not surprisingly centered mostly around the MGTaylor facilitation process. There were also several interesting thoughts and stories about collaboration in general. One group of participants chose to tell their story in murder mystery form, a surprisingly effective medium that ended up captivating quite a few people. (215)

Throughout the week, Alicia Bramlett, another Krew member, evolved the Wiki site design, highlighting content we felt was important. (She also put together a very cool movie of the event, which we showed to the participants on the last day, and which appropriately received a standing ovation.) The other Krew members and the facilitators were actively engaged in contributing to and gardening the Wiki throughout the week. (It should be pretty obvious at this point what I thought about these folks — they were awesome.) (216)

Watching people use the Wiki was a special treat for me. I learned tons about the tool’s usability, stuff I’ll report on eventually. Most people learned the tool quickly and easily. I had more trouble getting people connected to the wireless than getting people using the Wiki. (217)

I ended up adding a new feature to PurpleWiki — visited pages — during the event. I realized that several people were having problems navigating the site after editing the pages, and I knew that having a list of recently visited pages would help resolve that. It was already on our list of things to do, and it was an easy feature to add, so I did it. (218)

Shortly after the event, I was delighted to see a new function evolve from the Wiki. Because people were from all over the globe, one of the participants suggested that people post useful travel information on the Wiki, which several people did. (219)

I’ll have more to say on all of this at some point, including a more formal report of the results. (21A)

Manifesto Summit; More Responses

Published April 27, 2004 by Eugene Eric Kim

In the two weeks since I last responded to feedback about my manifesto, there have been several other interesting comments. Before I respond to those, I want to make a couple of announcements. First, this Thursday (April 29), I’m presenting the manifesto at SRI‘s Artificial Intelligence Center at 4pm in Menlo Park, California. The talk is free and open to the public. (1E2)

Second, Blue Oxen Associates is once again helping design this June’s Planetwork Conference in San Francisco. In addition to the usual lineup of great speakers, including TrueMajority‘s Ben Cohen (the “Ben” in Ben & Jerry’s), there will be a parallel interactive component. The format will be self-organizing, in some ways resembling Open Space, and is being designed by Tomorrow Makers (Gail Taylor and company) and Blue Oxen Associates. The purpose of the interactive component is to give people some basic infrastructure to discuss and work on topics of interest and also to enable different groups to connect and intertwingle. (1E3)

I want to build on some of the interest that the manifesto has generated, and the Planetwork Conference offers a perfect venue to do so. I’d like to propose a summit at this June’s conference for everyone interested in pursuing greater interoperability between collaborative tools. If you’d like to attend, drop me an email, register for the conference at the web site, and rank the topic. I’ll followup later with more details. (1E4)

On to the comments. (1E5)

Empowering the Programmer (1E6)

Several people forwarded Bill De Hora’s response to my manifesto. Bill quoted Chris Ferris: (1E7)

“Interoperability is an unnatural act for a vendor. If they (the customer) want/need interoperability, they need to demand it. They simply cannot assume that the vendors will deliver interoperable solutions out of some altruistic motivation. The vendors are primarily motivated by profit, not good will.” (1E8)

then added: (1E9)

There’s a class of articles that tend to look to assign blame to programmers for what’s wrong with software…. I find them ferociously, willfully, ignorant on how software actually is conceived, designed, marketed, built and sold. Blaming programmers is intellectually slothful. We are, and let’s be clear about this, decades past the time the blame could be laid squarely at the programmers feet. (1EA)

A Manifesto for Collaborative Tools veered close to that, while never quite getting there – exhorting developers, with only token gesture as to how decisions about software are made. Software is a complete commercial ecosystem that extends far beyond hacking code. Ironically like its observation of the semantic web, this manifesto is unlikely to take hold because it does not address the real issue, which is the marketplace and not technique. This failure in analysis is all the more frustrating as I agree with the essential sentiment expressed (we need better tools, now). Plus the writing is wonderful. (1EB)

My essay isn’t about blame, it’s about empowerment. Bill is right in that I didn’t thoroughly discuss the role of the marketplace. That comes next. The first step, though, is awareness. I’ve learned a lot from Doug Engelbart over the past four years, but the two lessons that stand out most in my mind are: 1. Making the world a better place is a reasonable career goal; and 2. The first step towards achieving this is to think bigger. Very few people — least of all, programmers — understand or want to understand collaboration well. Start with this problem first, then we can talk about the marketplace. (1EC)

Okay, so the cat’s out of the bag. I’m a closeted idealist. But the reason my idealist side is in the closet is that I’m also a realist. Less (or at least, as much as necessary) talking, more walking. I founded Blue Oxen Associates to help achieve this goal, and so in some ways, our continued existence and progress will be a measure of whether or not this vision can be achieved. (1ED)

So, how do we deal with the vagaries of the marketplace when it comes to interoperability, especially in light of Chris’s comments? Chris provides the solution. The solution has to start from the bottom-up — the users. (1EE)

The Identity Commons model (which fits right into the overall framework I describe) is a good example of this approach. These folks want to take on Microsoft Passport and Liberty Alliance. The goal is to provide an alternative digital identity infrastructure where individuals retain control over their information. Realistically, Identity Commons will not be successful by marching into the offices of various vendors with a technical spec in hand and pleading for it to be implemented. Their approach is to target a market sector that isn’t currently being addressed — civil society. Once users there recognize the utility and desirability of the infrastructure, they’ll demand it elsewhere. (1EF)

Beyond Collaborative Tools (1EG)

A few people observed that the principles espoused in the manifesto applied to areas beyond collaborative tools. Jamais Cascio said: (1EH)

Replace “tools” with “movements” (and “tool builders” with “activists”) and Kim’s argument clearly applies to not just to those who are making the technology, but also to those who are using the technology to build a better world. (1EI)

In his OLDaily newsletter, Stephen Downes suggested that the principles “are as applicable to e-learning software as collaboration tools.” (1EJ)

There’s a good reason for this. The steps I described apply to almost any collaborative scenario, be it activism or learning. I was especially happy to see Jamais’s comments, because that is ultimately what this is all about. (1EK)

Semantic Web Evangelists (1EL)

A few people who read early drafts thought that some Semantic Web folks might take offense at some of the things I said. For the most part, folks have been very positive. W3C’s Dan Connolly, however, expressed some frustration on the #rdfig IRC channel about my claim that Semantic Web evangelists are more machine- than human-centric in their pitches. (1EM)

Argh! Which evangelists? I’m certainly spending 99.9% of my time working on the balance between effort and reward for people. (1EN)

Tim Berners Lee for one. Tim and coauthors James Hendler and Ora Lassila opened their May 2001 piece in Scientific American on the Semantic Web with a science fiction scenario where automated agents collaborated with each other to schedule a doctor’s appointment. That scenario echoed tales of Artificial Intelligence’s past. (1EO)

Now I realize I just said that we need to think bigger, that the audience for this article was broad, and that the authors wanted to open with something sexy. I also don’t mean to pass say that Tim or James or Ora are not people-centric in their philosophy or work. I’m saying that these scenarios are not actually people-centric, even though they might seem that way on the surface, for reasons cited in the manifesto. That’s a problem, because a lot of people missed the point. This is less the case today than it was three years ago, but I worry that the damage has already been done, and the end result was that some of the outstanding work that has happened over the past three years (work to which I refer in the manifesto) hasn’t gotten the credit it deserves. (1EP)

Italian Translation (1EQ)

Luigi Bertuzzi is currently working on an Italian translation of the manifesto. You can read the email he sent to me and follow his work. (1ER)

December GivingSpace Workshop

Published December 22, 2003 by Eugene Eric Kim

There were several interesting presentations at Tom Munnecke‘s December 11 GivingSpace workshop, as well as some worthwhile discussion. Some quick thoughts and tidbits: (NA)

The workshop began with one of Paul Andrews‘s Improbable Pairs videos. This one told the story of Yitzhak Frankenthal, an Israeli whose son was killed by Palestinians, and Jawad Tibi, a Palestinian whose brothers were killed by the Israeli military. Their tales are gutwrenching, but rather than respond with hatred, the two formed a group called the Parents Bereavement Forum, a support group for both Israeli and Palestinian families personally affected by the violence. Paul filmed and edited their stories masterfully. The video was only about ten minutes, but there was not a dry eye in the audience. (NB)

Heather Wood-Ion gave a marvelous talk on transformation. An analogy she made that stood out for me was that the mythology in nonprofits centers around martyrdom. Words like “sacrifice” and “suffering” are bandied about. The mythology in forprofits centers around heroes. There, people talk about building legacies. These attitudes explain why nonprofits are so poor at collaborating with each other. There is a sense that martyrdom and collaboration are mutually exclusive. People want to share their stories of suffering, not of what went right and why. (There was some followup discussion about this at the Blue Oxen Collaboration Collaboratory.) (NC)

Megan Smith, one of the founders of Planet Out and currently a Reuters Digital Visions Fellow at Stanford and an employee at Google, explained the 2/3 rule: Two-thirds of every successful community on the Internet consists of conversations. Successful sites, she said, are good at gardening those conversations. Megan also described a giant LCD map of the world at the Google offices. When someone in the world queries Google, a light blinks at that location on the map. What strikes Megan is that there are entire regions of the world that are always dark, a vivid visual reminder of the digital divide. In addition to being a clear thinker and a dynamic storyteller, Megan also demonstrated a diplomat’s touch, when she very skillfully and transparently defused an exchange between participants that had gotten very heated. (ND)

Jerry Michalski explained his acronym du jour: MADA (Memory, Analysis, Discourse, Action). MADA struck me as an excellent (better?) synthesis for what Doug Engelbart calls CoDIAK (Collective Development, Integration, and Application of Knowledge). Jerry had the line of the workshop, when he pointed to the conversation map that Megan had drawn on the white board, and said, “All that discussion without memory and analysis is like going around in a giant circle jerk.” Jerry also suggested that business are partially to blame for why we don’t have better tools for group memory. Business of culture, he observed, don’t want us to have a memory. They want us to buy what they’re currently telling us we need. (See also my previous notes on group memory.) (NE)

Richard Gabriel talked about the Hillside Group and Pattern Languages. He said that the Hillside Group “practices an aggressive disregard for novelty.” Jerry, incidentally, called Pattern Languages “deglazed wisdom.” Jerry was on fire that day. (NF)

We participated in a Conversation Cafe for the latter part of the workshop. The topic was, “What can we do to create self-organizing systems that discover and replicate positive, scalable, small things?” We broke into several small groups, sat at different tables in the “cafe,” and drew on butcher paper as we talked. Here’s an excerpt from a previous blog entry about one of those conversations: (NG)

Another great example of the challenges of SharedLanguage cropped up at the GivingSpace workshop in SanFrancisco last Thursday. Six of us were discussing small, concrete steps that lead to transformation, and HeatherNewbold described how MattGonzalez? for Mayor campaign buttons had galvanized the progressive community in SanFrancisco. Four of us knew exactly what Heather was describing, because we lived in the Bay Area and followed local politics. All she had to do was mention the buttons, and we understood what she meant. The other two people at our table, however, had no idea what we were talking about. One was from SanDiego, and the other simply didn’t follow politics. T (NH)

Here are the two products of the conversations at our table, courtesy of Fen Labalme. (NI)

Every time I participate in one of these workshops, I find myself paying close attention to the facilitation itself, inevitably comparing it to other experiences. Shelley Hamilton’s technique shared some similarities with the MGTaylor process, and at one point, she cited Stuart Kaufman’s work, which also inspired Matt Taylor and Gail Taylor. Overall, Shelley did a good job. I especially liked the Conversation Cafe. The one thing I didn’t like was that there was no Report Out session following the cafe. It would have been nice to have had a group session where we summarized our conversations and sought connections between those summaries. (NJ)