Identity Commons Sessions Summary (June 21, 2006)

Posted on Published by Eugene Eric Kim

There were two sessions on Identity Commons on the Open Space day (June 21, 2006) at the Identity Mashup at the MIT Media Lab last week. The first session was an open status meeting for the community at large. We described Identity Commons‘s purpose, told the history of the organization, then explained how the organization could serve the community today and why the existing organizational structure wasn’t adequate. We then announced that the current trustees had authorized a brand transfer, assuming that the new organization adopted purposes and principles consistent with the current purposes and principles.    (KQL)

Both sessions were well-attended, and there were a number of new faces. Interest in participation seemed strong.    (KQM)

In brief:    (KQN)

  • There are a number of grassroots community projects that involve multiple stakeholders and that are happening independently of any centralized direction.    (KQO)
  • These decentralized efforts could all benefit from some shared infrastructure, which could be as simple as a shared, neutral brand (i.e. “Identity Commons“) or as complicated as a set of rules that help ensure fair participation and governance among multiple parties.    (KQP)
  • Our strategy is to build an organization organically that addresses the needs of these different community projects.    (KQQ)

Current projects/interests (and stewards) include:    (KQR)

These projects could benefit from things like:    (KR1)

  • Shared name. The importance of this can’t be understated. It demonstrates solidarity, implicit community cooperation, which is particularly important for this community. There’s also an implicit reputation (hopefully positive) associated with a shared name that encourages participation in the community.    (KR2)
  • Bank account. Several of these projects need a bank account. A great example of this are the various community gatherings, which need the ability to accept registrations and spend money on things like space rental and food.    (KR3)
  • Online community space. Many of these groups are already using mailing lists and Wikis for discussion and group authoring. It would simplify things for new groups if these resources were easily available to those who wanted them. It would also benefit the community at large if some of these groups had their discussions on a shared space as opposed to separate silos.    (KR4)
  • Governance and process. Some fundamental guidelines can help all groups facilitate cooperation and participation from all stakeholders.    (KR5)

Eventually, what we’re currently calling “Identity Commons 2.0” will need:    (KR6)

  • legal entity w/ bylaws and membership criteria    (KR7)
  • financial model    (KR8)
  • intellectual property agreement (potentially using Apache Software Foundation as a model)    (KR9)

Our strategy for addressing these needs is to attack the low-hanging fruit first and to let the projects drive the priorities of the organization. We will start by forming an organizational working group consisting of the stewards of each of the working groups described above as well as anyone else from the community who wants to join. Its first meeting is a teleconference tentatively scheduled for next Thursday, July 6 at 9am PT, pending confirmation from the different stewards. (Details to be announced on the community mailing list.)    (KRA)

Organizational policy should be as lightweight as possible, giving each working group the option of customizing them to fit their needs.    (KRB)

We will use the community mailing list for discussion. We will also setup a Wiki, leveraging the work Jon Ramer did for Identity Mashup. We will look into merging some of the other Wikis, such as Identity Gang, into this new Wiki.    (KRC)

Who will decide what working groups form or what collaborative tools we’ll use? In general, if someone wants to propose something that’s consistent with the purposes and principles, the answer is “yes” — provided someone is going to steward the proposal.    (KRD)

Developing Shared Language

Posted on Published by Eugene Eric Kim

Drummond Reed recently wrote about the Identity Rights Agreements session at last month’s Internet Identity Workshop. While the outcome was fruitful, Drummond wrote, “The biggest frustration was that after an hour and fifteen minutes we were just really getting started – we needed a good half-day on the subject.”    (KNJ)

Jamie Dinkelacker told me a similar story last year in describing a SOA gathering of gurus. The goal was to share knowledge and to advance the state of the art, but the participants spent most of their time arguing over the definition of “services.”    (KNK)

The problem in the first case was with expectations. The participants should have expected some ramp-up time would be necessary to get started, because they needed to establish some Shared Language. The problem in the second case was with process. The participants did not have an effective strategy for developing Shared Language, and thus, the latter ended up monopolizing the whole workshop.    (KNL)

Shared Language is a prerequisite to collaboration. Without Shared Language, we can’t collaborate. It’s as simple as that. When a group tries to collaborate without having Shared Language, the group will try to create it, whether it’s aware of it or not. This creation process is often frustrating and painful, and as a result, people sometimes try to skip this step or belittle the process. This is a problem. You can’t skip this step.    (KNM)

When designing collaborative spaces — both online and face-to-face — you have to build in time and space for developing Shared Language.    (KNN)

If you examine every good collaborative, face-to-face process for large groups, you will find that all of them generally recommend a minimum of three days. I haven’t found a rigorous explanation for why three days work so well, but the pattern is consistent, and we can certainly speculate. Much of it has to do with building in enough time to develop Shared Language. (Michael Herman, Open Space facilitator extraordinaire, has suggested that it’s less about the three days and more about the two nights — having our minds go through two natural work-process-rest cycles. I think he’s onto something.)    (KNO)

The first day is always about developing Shared Language. MGTaylor calls it the “Scan” day. Phil Windley calls it the “butt-sniffing” day. Regardless of what you call it, you need to design for it. It’s going to happen whether you like it or not. The question is whether or not it will happen effectively while leaving time for action.    (KNP)

There are two myths regarding how you create Shared Language. The first is that “shared” is equivalent to “same.” They’re not. Shared Language means that you understand how others around you are using terminology. Some level of sameness is obviously useful, but when you’re dealing with something relatively complex, sameness is both impossible and undesirable.    (KNQ)

I devised a metric several years ago called the Squirm Test that’s similar in concept to Wikipedia‘s Neutral Point Of View. The test is simple. Sit your team around the table. Have each person stand up and give a brief project description and status report. During the pitch, no one is allowed to talk, other than to ask clarifying questions. You have a perfect level of Shared Understanding and Shared Language if you make it around the room without anyone squirming.    (KNR)

The second myth is that creating Shared Language consists of creating a dictionary. That’s certainly one way to approach it, but it’s not the only way, and often times, it’s not the best nor the fastest way.    (KNS)

There are three elements to creating Shared Language:    (KNT)

  • Share individual contexts    (KNU)
  • Encourage namespace clash    (KNV)
  • Leave enough time and space to work things out    (KNW)

Sharing individual contexts is a fancy way of saying, “Know your audience.” Or, more accurately, know who you’re working with — their world view, their values, etc. You don’t have to use the same terminology the same way; you just have to understand what people mean and where they’re coming from. For some techniques on how to do this, see Collab:KnowTheParticipants.    (KNX)

I’ve written many times about how Wikis and tagging encourage namespace clash, which in turn encourages Shared Language. From a facilitation standpoint (both face-to-face and online), if you pose questions that stretch the mind, you also draw out namespace clash. MGTaylor is especially good at doing this with its Design Shops. Allen Gunn uses a technique called a spectrogram where you stretch a piece of masking tape across the room, ask a controversial question, then tell people to go to the place on the tape that represents their position on the question. You then ask people along the spectrum why they’re standing where they’re standing, and you give people the chance to move around based on other people’s answers. If you ask the right question, you’ll not only quickly get a great sense of your audience, but you’ll also draw out different interpretations of language.    (KNY)

Finally, simply scheduling time and space where Shared Language is the primary goal is useful. People are good at figuring out how to communicate with each other if you give them the space to do it. If you set unrealistic expectations on the first day of a three day event, then you just stress out your participants. If you spend the first day exploring broader questions, your participants may feel flustered or frustrated, but they will find that the work goes much more smoothly in the ensuing days.    (KNZ)

Developing Shared Language is an ongoing process. Doing actual work is one of the best ways to build shared context, which in turn builds Shared Language. The trick is to have stagger your work goals based on the Shared Language that already exists. The exercises you go through can become more and more focused over time, as the amount of Shared Language increases.    (KO0)

At the Blue Oxen Associates Tools for Catalyzing Collaboration workshops — one-day workshops with about 25 participants — we don’t do participant introductions. We assign teams and have people go straight into their exercises. However, we pay careful attention to how we assign the initial teams, and we structure the exercises accordingly. For example, at our January workshop, we started by pairing people who either already knew each other or were in similar fields, and we had them start their exercises immediately. We then grouped pairs and had them present their work to each other. Finally, we had a plenary session where each group reported on their work, followed by a plenary discussion. Our participants were engaged right away, and the shared experiences acted as an icebreaker, which made it easier to meet new people and to talk in our designated networking times (e.g. lunch). We also had online profiles up on our Wiki, so that people could find out more about the other participants before, during, and after the workshop. Several people commented afterwards about the lack of group introductions. All of them liked it.    (KO1)

Angry Rant on Wikis

Posted on Published by Eugene Eric Kim

Earlier this month, Jonas Luster invited me to speak at WikiWednesday. I didn’t have anything prepared, and I didn’t feel particularly motivated to prepare anything, so, I told Jonas that I was just going to rant. Jonas, being Jonas, loved the idea. So after IIW wrapped on May 3, I headed up to Palo Alto. I promised folks at IIW that I was going to give an angry rant on Wikis, and so several people decided to come watch, including Phil Windley, who blogged it. Feedback was great, except for a few complaints that I wasn’t all that angry. I promise to get more worked up next time, folks.    (KK2)

I’ve made all the points I made in my rant before in some form or another, often on this blog. Nevertheless, it was the first time I shared these ideas as one semi-cohesive thought, and so it’s worth rehashing the points here.    (KK3)

Overview    (KK4)

There are two things that make Wikis cool:    (KK5)

Lots of folks have latched onto the open access part, and there’s been some interesting exploration in this area. Very few folks know about or understand the Shared Language aspect. I think this is a huge loss, because it’s what makes Wikis truly transformational.    (KK8)

Open Access    (KK9)

Since I had just come from IIW, I started with digital identity. First, I said that all Wikis should support some form of distributed Single Sign-On, be it OpenID or something else. Implementing Single Sign-On does not imply loss of anonymity. Most Wikis give you the choice of logging in or not; implementing Single Sign-On would give you the additional choice of using a single identity across multiple sites.    (KKA)

Why would this be useful? Consider Wikipedia. As my friend, Scott Foehner, commented in a previous post on this topic (to be visible again when I turn comments back on), Wikipedia actually consists of a number of different Wikis, one for each language plus a number of special Wikis, such as its community site. Each of those Wikis require a separate user account. Not only is this a huge inconvenience, it effectively prevents you from having a single digital identity (along with your associated reputation) across each of these sites.    (KKB)

Simply having Single Sign-On across all of the Wikipedia Wikis would be valuable. More importantly, the identity community has converged to the point where it doesn’t make sense to roll your own protocols. There are several good existing protocols to choose from, and many of those are in the process of converging.    (KKC)

Reputation is closely associated with identity, and it’s also been one of the most popular topics in the Wiki community over the past year. However, most people have a misguided notion of what reputation is and what we should do about it. Reputation is what others think about you. Reputations exist in every system, whether or not they are explicitly represented. Reputation cannot be quantified. However, you can identify the factors that determine reputation and make those factors more explicit.    (KKD)

In Wikis, this could manifest itself in a number of ways. For example, one way to determine the quality of a page is to view the number of people who have edited it. You could make that number explicit by subtly changing the background color of that page — slightly yellowed for a page with few contributors and bright white for a page with many contributors.    (KKE)

The important point here is that you are not making a value judgement on reputation. You are not saying that a page that has many authors is better than a page that does not. All you are doing is making it easy to see that a page has many authors. Readers can determine for themselves how much weight (if any) to place on this factor for the reputation algorithm in their heads.    (KKF)

The most important button on a Wiki page is the Edit button. That button implies Permission To Participate. It should be one of the most visible buttons on any Wiki. If a Wiki looks too good, that discourages participation. Who wants to edit something that looks like a finished product? Ward Cunningham used to suggest sprinkling typos across a Wiki page to encourage others to participate.    (KKG)

At this point in the rant, I plugged both Ward and MeatballWiki. The Wikis success is no accident. A lot of the fundamental design features that make Wikis powerful were completely intentional, a testament to Ward’s brilliance. Additionally, most of what I ranted about is not new to the Wiki community. A lot of it — and more — has been discussed on the venerable MeatballWiki. If you really want to get a deeper understanding of how to improve Wikis, you should be on Meatball.    (KKH)

Shared Language    (KKI)

Last September, I wrote:    (KKJ)

What really makes the Wiki’s LinkAsYouThink feature special is that it facilitates the creation of SharedLanguage among the community that uses it. As I’ve said so often here, SharedLanguage is an absolute prerequisite for collaboration. The lack of SharedLanguage is the most common roadblock to effective collaboration, be it a small work team or a community of thousands.  T    (KKK)

It bears repeating over and over and over again. Wikis are transformational because they facilitate Shared Language. This is a feature that should be propagated far and wide, both in Wikis and other Collaborative Tools.    (KKL)

I noted two possible convergences. The first is Wikis and tagging. They both share a similar principle, namely namespace clash, and we should look at ways of combining these two concepts. For example, where’s the tag cloud view of a Wiki’s page index? Another idea: Clicking on a tag should also return Wiki pages of the same name. Technorati should be indexing Wiki pages and treating their titles as tags.    (KKM)

The second is implementing Link As You Think in all tools. Blogs that are built on top of Wikis (such as TWiki and JotSpot) have these features, but you don’t have to build a tool on top of a Wiki for this to work. This blog runs on blosxom, but it has Link As You Think. Chris Dent‘s blog runs on MovableType, and it has the same feature. It shouldn’t just apply to blogs, either. It should work in web-based forums and other Collaborative Tools.    (KKN)