E-Advocacy Brown Bag Discussion

Emy Tseng invited me and about 10 others to join her at the Community Technology Foundation in San Francisco for a brown bag discussion of e-advocacy, especially relating to underserved communities. The folks I meet through Emy are always interesting, and I especially appreciated the ethnic diversity of those attending this meeting. I don’t get too caught up with race when it comes to my work, but I’m definitely conscious of the fact that most of the folks in this space are white men.    (2FS)

Some quick takeaways and thoughts:    (2FT)

  • Advocacy tools need better multilingual support. It’s not enough to localize tools; you also have to make them usable.    (2FU)
  • There’s certainly a lot of room for folks in the e-advocacy space to collaborate. But the real problem is not choosing tools, but knowing what online capabilities exist and how they can be integrated into an overall advocacy strategy.    (2FV)
  • Many small to midsize nonprofits struggle simply to keep their computers running and their email working. Transitioning to using more sophisticated tools is a big, big step.    (2FW)
  • Some people brought up issues regarding in-fighting within coalitions over who owns or controls mailing lists. Identity Commons offers an interesting technical solution to this problem, in that it gives control to the individual.    (2FX)
  • Several folks talked about the need for techies to avoid jargon and speak in a language these organizations understand. I disagree. Shared Language is not one over the other; it’s different communities developing Shared Understanding. There’s no one-to-one translation between technical and nontechnical concepts. Techies have to work to understand users, but users also have to work to understand technology. Only then does Shared Language emerge and coevolution becomes possible.    (2FY)

ChiliPLoP, Day 4

Last Friday was the last day of Chili PLoP. Ofra Homsky, Josh Rai, Linda Rising, Joe Yoder, and I met at our usual spot outside of the dining hall for our morning kickoff. We had two items on our agenda: workshop the patterns we had discussed the day before and that Josh and I had written up, and discuss next steps.    (1DF)

Stone Soup    (1DG)

We started with Collab:StoneSoup and decided to temporarily combine forces with the GivingSpace group, which had independently come up with a pattern of the same name. That experiment resulted in some constructive feedback but was short-lived. The most important lesson was that “Stone Soup” was a completely inappropriate name.    (1DH)

The pattern had arisen from a point I had made the previous day about faith in process. I stated that people about to participate in a new process had to demonstrate a certain amount of faith up-front; otherwise, they risked subconsciously hijacking the process. You want to give the process the chance to succeed or fail on its own merit.    (1DI)

Joe suggested calling this pattern, “Fake It ‘Til You Make It.” Ofra was reminded of a story, “Stone Soup,” which went like this.    (1DJ)

A weary soldier discovered a village in the desert and knocked on every door asking for food. Everyone turned him away.    (1DK)

Undaunted, the soldier took his pot, filled it with water and a large, round stone, and put it over a roaring fire, constantly stirring and tasting.    (1DL)

The curious villagers came out of their houses and watched, until finally, one of them asked how it tasted. The soldier replied, “It’s good, but it needs some salt.” So the villager went inside her home and brought out some salt.    (1DM)

She again asked the soldier how the soup tasted, and he responded that it could use some carrots. So another villager brought some carrots. The process repeated itself until eventually, there was enough tasty soup to feed the entire village.    (1DN)

During our group writing exercise, it quickly became apparent that we all had slightly different understandings of the pattern. Mine focused on the point of view of the participant and on adopting new processes. Everyone else seemed centered on initiating new collaboration, setting up enough structure to make the collaboration seem real, at least until the collaboration became real.    (1DO)

When I started refactoring and combining our work into a single pattern, I decided that there were multiple contexts for the same pattern, but that the solution was the same. I also decided to call it, “Stone Soup” instead of “Fake It ‘Til You Make It,” mostly because the former was a noun phrase. I had reservations, however, and our final day’s proceedings confirmed them. When we combined with the GivingSpace team, it became clear that there were at least three different versions of the Stone Soup story, each with different morals.    (1DP)

After we split with the GivingSpace group, my team continued giving feedback about what I had written. I picked up lots of good advice and promised to incorporate their comments into a revision.    (1DQ)

Kick Off    (1DR)

I was happy when Josh willingly took on the Collab:KickOff pattern, because I didn’t think we were close to Shared Understanding. That said, Josh’s work on the pattern helped us make that leap.    (1DS)

Originally, we called the pattern, “Kick Off Meeting.” I had asked whether the Kick Off meeting was, by definition, the first meeting. Ofra and Joe had said that it was not. However, as we started fleshing out the pattern, it wasn’t clear to me what the distinction was. People were mentioning a lot of things that supposedly happened at Kick Off meetings that I felt would happen regardless of whether or not a meeting was designated, “Kick Off.” The key distinction, in my mind, was whether or not those things would happen well. It wasn’t clear to me that denoting a meeting “Kick Off” was enough to make those things happen well.    (1DT)

Josh’s work on the pattern made some of those flaws apparent. Having something concrete to work from allowed us to quickly zone in on the vital piece — benefits from the ritual celebration of initiating a new project. We decided to remove “meeting” from the name.    (1DU)

In the end, this made perfect sense to me. We had defined collaboration as needing shared, bounded goals. We had also cited a pattern, Grand Finale (discussed in Linda and Mary Lynn Manns‘s upcoming book). It made sense that we also had a pattern for the beginning of a project as well.    (1DV)

Next Steps    (1DW)

One of the things I made clear to the group was that I considered this workshop to be the Kick Off to Blue Oxen Associates‘s ongoing Pattern Language effort. One of my broader goals is to do an ongoing series of workshops involving philanthropic foundations, nonprofits, and a variety of other organizations. These workshops would involve telling stories, mining for patterns, capturing those patterns, reinjecting them into the conversation, refining them, and so on.    (1DX)

In the meantime, I plan on further developing the language that began forming at our workshop with the help of our Collab:PatternsWorkGroup. I also plan on submitting some patterns to the PLoP conference in September.    (1DY)

I had an exceptional time at Chili PLoP. Lots of great people were there, and Arizona is warm and beautiful this time of year. More importantly, I was fortunate to have a great group of participants. Ofra, Josh, Linda, and Joe brought a tremendous amount of experience and enthusiasm to the process, which made the process both enjoyable and productive. I’m looking forward to the challenge of continuing what we started here, including another date at next year’s Chili PLoP.    (1DZ)

ChiliPLoP, Day 3

Last Thursday, my workshop met for a second day. Having agreed on a working definition for collaboration (see Collab:Collaboration), we started working on the Pattern Language. As was the case the previous day, I knew exactly what I wanted to accomplish, and I made that clear when we got started. What differed this day, however, was that Linda Rising, Ofra Homsky, and Joe Yoder — our three experienced Pattern Language authors — led the way in terms of process.    (1CT)

We began by laying out the index cards we had collected the previous day onto a table. The goal was to see what patterns we had and what seemed to be missing. The definition that we had collectively agreed on the day before helped us tremendously with this process. For example, because collaboration — as we defined it — required bounded goals, that meant there were patterns related to the start and end of the collaborative process. There were also patterns related to interaction (meetings for example) and knowledge exchange (Shared Display).    (1CU)

Mapping out our cards also helped us identify gateways to other Pattern Languages, such as Linda and Mary Lynn Manns‘s patterns for introducing new ideas into organizations, Ofra’s patterns for leadership, Jim Coplien and Neil Harrison‘s organizational patterns, and GivingSpace‘s patterns of uplift.    (1CV)

Lots of brainstorming and storytelling happened throughout. My favorite was a story that Joe Yoder told about a factory where he had previously worked, which literally left its financial books open on the factory floor. Anyone who worked at the company could examine the books and suggest improvements. The open books were a form of Think Out Loud that showed that the company treated its operations as a collaborative process involving all of its employees, regardless of position. Tremendously empowering stuff.    (1CW)

Linda, Ofra, and Joe constantly stressed the importance of iteration and cautioned Josh Rai and me about getting too caught up with formality too early in the process. Ever fearful of being berated by Ralph Johnson or Jim Coplien, I would periodically complain, “That name isn’t a noun phrase!” Fortunately, the rest of the group kept me on track. We had plenty of time to weed out and refine our patterns after the brainstorming process.    (1CX)

We ended our brainstorming at lunch, at which point we had 36 cards. After lunch, we picked two patterns — Collab:StoneSoup and Collab:KickOff — and Linda led us through a group pattern writing exercise. (I’ll say more about these two patterns when I describe Day 4.) She gave us a letter-sized piece of paper for each component of the Coplien Form (name, problem, context, forces, solution, rationale, resulting context, known uses, and related patterns). Each of us took one piece of paper, wrote down our ideas, then exchanged it with someone else for another piece of paper. The cycle continued until we all had our say to our satisfaction. Afterwards, we discussed what we had written.    (1CY)

This was the first time Linda had tried this particular exercise, and I think it worked very well. It was particularly good at helping us reach Shared Understanding. We all had slightly different views of both patterns. Actually going through the group writing process helped make these differences explicit, at which point we were able to talk through our differences.    (1CZ)

Because Josh and I were the pattern-writing newbies in the group, we each collected the sheets for one of the patterns and promised to combine, edit, and rewrite them into a readable draft. I chose Collab:StoneSoup; Josh took Collab:KickOff. The plan for Day 4 (which was only a half day) was to workshop our results.    (1D0)

I ended the day with a brief overview of how blogs and Wikis integrated with Backlinks could be used to tie stories with corresponding patterns.    (1D1)

Chili Beer    (1D2)

Since that night was our last in Carefree, I decided to organize a margarita BOF. Earlier, somebody had told us about the Satisfied Frog, a legendary Mexican restaurant and bar that had “a thousand different kinds of margaritas.” This was the obvious place to hold our BOF, so Josh, Jerry Michalski, Gerry Gleason, and I trekked on over.    (1D3)

As with most legends, the facts had been slightly exaggerated. The Satisfied Frog only served one kind of margarita, although in fairness, it did give us the option of frozen versus on-the-rocks and with or without salt.    (1D4)

The restaurant did, however, brew its own special beer — chili beer — which was bottled with a serrano chili pepper. It had a nice kick to it, but it wasn’t overpowering. I recommend it to those with a a penchant for adventure and a bit of a heat tolerance.    (1D5)

ChiliPLoP, Day 2

Today, my workshop began in earnest. My goal for today was to collectively
develop a working definition of collaboration, and I’m happy to say
that we achieved that (see Collab:Collaboration). Tomorrow, we’ll
start exploring patterns in earnest.    (1BW)

I have a great group of participants:    (1BX)

We began the day by introducing ourselves to each other. I asked each
person to relate their best collaborative experience. Most people
found it a difficult question, which jives with my overall
experience. Nevertheless, we managed to get enough out of the stories
for a barebones definition to emerge.    (1C2)

I then sent the participants off to read Chapter 4 of Michael Schrage’s
No More Teams! while I refactored my Dialog Map, captured using
Compendium.
(I’ll post the final map at the end of the conference.)    (1C3)

After lunch, I showed the participants my Dialog Map for the first
time. From that point forward, the map became part of the
conversation (Shared Display). We walked through several scenarios —
some of which had emerged from the earlier discussion — deciding
whether or not they constituted collaboration and why.    (1C4)

Afterwards, I refactored the map again, and we started refining the
definition. The end result is at Collab:Collaboration. I’ll post
more commentary on the patterns mailing list.    (1C5)

Throughout the day, all of us recorded possible patterns on index
cards. We’ll use those as a starting point for our discussion
tomorrow.    (1C6)

Side Notes    (1C7)

I had made my expectations very clear at the beginning of the day: My
goal for the day was to have a working definition of collaboration.
(A pattern Ofra calls Set The Pegs.) So, having accomplished that at
the end of the day, we all were satisfied.    (1C8)

On the way to dinner, I ran into another workshop participant who
asked me how my workshop went. I said, “Great. We defined
collaboration.” He thought I was joking. We had spent the entire day
defining one term, and I was actually happy about that.    (1C9)

This was very much by design, and to be perfectly frank, I was glad
that we managed to come up with something workable by the end of the
day. I am a strong believer in Shared Understanding as a prerequisite
for effective collaboration. I’ve also been influenced by the
MGTaylor process, which suggests that spending about two-thirds of the
allotted time on Shared Understanding and Shared Language and the rest
on the concrete objective is actually more effective than attempting
to spend all of the time on the concrete objective. The reason is
that you are not capable of effectively attacking the concrete
objective without first developing Shared Understanding. The end
result is that you end up trying to solve both problems simultaneously
(and often unconsciously) and up doing both poorly. Additionally,
because you were not realistic with your expectations up-front,
everyone walks away disappointed.    (1CA)

The proof, of course, is in the pudding. It’ll be interesting to see
how my participants feel about our overall productivity by the end of
the day tomorrow.    (1CB)

Earlier that day, I described Blue Oxen Associates to another attendee,
who wondered, how will we make money if we give our pattern language
away? He was actually trying to tactfully ask how we make money,
period. I don’t think he realistically thought that we could make
money selling a “proprietary” pattern language.    (1CC)

My response: The real value is in the experience, not in the text
itself, which without context is simply more information in the
infoglut. If you can gain value from merely reading our material,
outstanding. We give it away to heighten the potential impact.
However, to truly appreciate the research, you need to experience it
firsthand. I see Blue Oxen Associates as a new type of learning
organization, where members learn by experiencing and participating in
what we study and what we learn. The value is in the experience and
in being part of our community, and that’s what we expect people to
pay for.    (1CD)

Finally, in the evening, Jerry Michalski demonstrated The Brain, a
Personal Knowledge Management tool. Sadly, it was late in the evening,
and only a few people saw the demo; tomorrow, I’m going to suggest
that he do it again. I had seen The Brain before, but Jerry’s demo is
particularly compelling because he’s been adding data to it since
1997.    (1CE)

One thing that really comes through with The Brain is how little
semantic richness you need for a tool to be useful. The Brain supports
typed links, but Jerry doesn’t use them. Instead, he uses topical
nodes to relate other nodes. In essence, it’s a barebones graph model
with a great UI, but its utility is tremendous. We don’t have enough
tools like it.    (1CF)

Manifesto Comments, Responses

Many thanks to everyone who’s emailed me or blogged about my manifesto. I’ve received great feedback — lots of kind words and constructive comments — both via email and the blogosphere. Because of the good folks at Slashdot, the piece was widely distributed. The last time something I wrote was Slashdotted, the responses were mostly content-free. This time around, quite a few people there had something reasonably substantial to say.    (1AS)

Where’s The Beef?    (1AT)

The most asked question was, “Where’s the beef?” Krysztof Kowalczyk wrote:    (1AU)

It points out problems, shows some meta-solutions but almost no concrete solutions.    (1AV)

Marc Canter added:    (1AW)

There’s nothing he’s saying that I don’t agree with. I just wish he’d get more specific. Screen shots, Mockups, Design guidelines, Wireframes. APIs. Schemas. We need more Schemas!    (1AX)

The point of my backlinks example is that in many cases, concrete solutions already exist; we just haven’t collectively realized it yet. Collaboration can’t happen until we realize that we’re all working on the same problem. There are initiatives for achieving this Shared Understanding, including our Collaboration Collaboratory and OCSI.    (1AY)

That’s the more technical part of the “beef.” However, there’s a sociological element that has to come first: We have to understand what it means to collaborate, and we have to understand how we collaborate. Again, pockets of understanding exist, although they are mostly isolated from each other. We need to unify that understanding.    (1AZ)

Patterns of Collaboration    (1B0)

Blue Oxen Associates is working on that part of the problem. Our approach is to mine for patterns of effective collaboration and to disseminate these patterns widely via a Pattern Language. We’ve hinted at this objective in previous research reports, and we’re further refining it via additional research and other projects. Tomorrow, I’m heading to Carefree, Arizona for Chili PLoP, where I’ll be leading a workshop on patterns of collaboration.    (1B1)

On Slashdot, Jameth commented:    (1B2)

The manifesto makes grand claims about unifying our collaborative language, but totally understates how difficult this is. The problem usually is that we just do not have a solid model of what can and cannot be done, and we likely never will.    (1B3)

Jameth later added:    (1B4)

Collaboration methods change day-to-day. Sometimes the methods change due to whim, sometimes due to fashion, and sometimes due to technology. Whatever the reason, collaboration methods are hard to nail down reliably.    (1B5)

I’m mostly with Jameth here. If I understated the difficulty of unifying our collaborative language, then I did so in error. It is a tremendous challenge. However, his claim that collaborative methods change day to day is incorrect. Perhaps that’s the case for methods in general, but it’s not the case for effective methods. The problem is that we’ve done a poor job of identifying and sharing these methods. This is exactly the problem we’re trying to address.    (1B6)

Metamodeling    (1B7)

Dorothea Salo wrote:    (1B8)

ARGH! Every time I think the One True DTD business has finally run its course?    (1B9)

…    (1BA)

Tell you what, dear heart. You tell me what the “fundamental constructs” of documents actually are — every document on earth, mind you — and I’ll happily help out with a standard way of expressing ’em.    (1BB)

I absolutely do not believe in this notion of “One True DTD”; in fact, I have spoken adamantly against it in the past. As I explain in the manifesto, the fundamental constructs I’m talking about are graphs. Every document can be expressed as a graph. XML fundamentally relies on this property, as its underlying data model is a graph. The point of my piece is, don’t get too caught up with syntax (although don’t ignore it either); focus on the data model.    (1BC)