Hapgood

There’s a really excellent post over at Frances Bell’s blog talking about problems with forking in fedwiki — and really about the meanings associated with different types of revisions and decisions of people.  And there’s a lot there to comment on, but the piece I take away is that we haven’t reduced the stress of revising work of others as much as we intended.

As Frances points out, sometimes this is because we don’t see the edits we should — and that’s a system issue.  But sometimes it’s that we do have the edits we want, but we’re just feeling pressure to adopt “the latest version” and we’re very worried someone’s contribution might have gotten lost. Sometimes it’s that we’d love to incorporate edits, but we’re newbies, and we go about things in ways that create more confusion.

I started writing a long comment on Frances’s blog, but got routed to a weird WordPress login loop. And I thought rather than go back and reconstruct that comment, I might put out a way of thinking about fedwiki for your critique. This doesn’t quite answer the questions or issues in that post (or the many, many comments), but it deals with the *stress* that misfires might cause newbies in the system. Because the misfires are a problem, but it’s the stress that worries me most.

A Kindle Parable

Imagine a world where everbody has a Kindle, but they are not that sucky, closed system you usually get stuck with. These Kindles allow you to treat your books like a word-processing document. You can add notes, change things, delete passages. And you can forward your annotated & edited version to all of your friends — the license allows you to do that.

So, for instance, I am reading Memory Machines right now, and the chapter I am on is the one on Englebart’s NLS project.

Now I know a bit about Englebart. And so as I’m going through it I’m writing in notes, and linking it up to other books I’ve read and other documents I’ve written. There’s also a bunch of stuff in there that’s not really relevant to what I am reading it for, and I delete it, knowing that when I come back to this to review it I want it to be short and scannable.

I also know I am going to share it with friends, and they won’t read it if it’s super long, so I edit it down to the pieces that really deal with federated wiki, since that’s what we’re talking about.

You (a friend of mine) get my annotated copy on this Kindle book and start making notes, adding some stuff, linking to the books that you have.

Now, here’s the thing — I see your edits. What does it mean if I don’t pull them back?

You can’t make it mean *nothing* — I’m not so naive as that. But I would love it to mean *less*. I’d like it to mean, primarily, that for my own reasons it wasn’t useful to me to pull those edits back.

Underlying that could be a number of things. Maybe I didn’t have the time. Maybe I missed them. Maybe I read them, and enjoyed them, but thought, hey — I can always read this version on your site, no need to fork back. Maybe someone had even better notes, and so I forked theirs and I didn’t want to take the time to integrate your notes in.

Basically I have me, and the people who read my annotated versions of books, and those are my responsibilities. My job is to write the best article I can given the time, but “best” is heavily influenced by what my personal needs are and who I feel I am writing for.

The one thing that best really shouldn’t consider too much is “What article will make my collaborators happy?” because that way madness lies. And that way self-editing lies too — and keep in mind if you’re afraid to say something that you think is useful, it’s likely we all lose.

The Fast Cooperation Problem

So this sort of system is properly called cooperative, not collaborative.

In collaborative systems, people share goals. In Wikipedia, that goal is to write the best and most representative neutral point of view article on a subject, in an encyclopedic style accessible to a general audience. You may have personal goals in addition to that (raising profile of women in science, for example) — but they must remain aligned with the group goal — they can’t supercede it.

In cooperative systems people are allowed to pursue wildly different goals, but are encouraged to do so in ways that can benefit the work of others. Blogging is in some sense cooperative — you pursue your own goals, but you publish in a way that makes your stuff easily quotable by others. The notation system that Kindle currently has, where I can see what Gardner Campbell highlighted is cooperative.

Federated wiki is cooperation dialed up to eleven. Or it’s meant to be.

But looking at the interactions and the confusions and stress that sometimes results, I’m starting to see a failing point.

Here’s the world as I imagined it. I publish an article on NLS. A bunch of people read it and put in their notes. Or just save it. I’m an attention addict, so maybe I immediately read the notes. But I don’t want to pull them back.

Why? Well, I read them, and some were good, But I don’t want to edit this thing every day. I’ll wait for some more notes to accumulate.

Other people fork my article and write their notes, edit their version. Some fork forks of forks. Each one is different. This happens over the space of weeks or months.

At some point I’m writing another article and I link to the NLS article. When I test out that link I see that there are a half dozen twins. I think, I should look at integrating some of this stuff and I browse the twins. and write stuff up.

This is my dream world, but there’s a couple of problems with this. First, we have cross-page item dragging, but it doesn’t create references in the history. So I am pushed to fork a version to get the reference, but all the versions are different, and forking destroys my own history.

This is a big part of the “catch-up” problem. If things get too out of sync it’s hard to put them back together while maintaining attribution. This can be fixed.

Harder to deal with is the different sort of environment our Happenings present.  In the Happenings we’re on the time-scale of hours, not days. It’s a sort of a “wikiswarm”, and it has the benefits and drawbacks of swarm behavior. So people all pounce on the same article at the same time.

That changes the dynamic dramatically. And I’d argue that it dials up the meaning of whether you get forked or not forked, or have your edits included or excluded. It certainly creates an environment where I feel I must stay on top of new edits, for the good of the tribe.

Possible Solutions

Some upcoming software upgrades (particularly a “history for paragraphs” upgrade) will make this much better. But the social issues remain.

It may be we need to encourage certain behaviors in Happenings that we don’t need to encourage in slow-cooperation environments. I’ve noticed that linking small articles out tends to work better than doing larger pages. When you create a small article with your additional idea, example, or data that idea stays visible even if the main article gets slammed with edits.

It maybe that we need to encourage “random article” behavior, to push people into editing the things that are not where the buzz is. We definitely need to get people to attribute less meaning to inclusion and exclusion of edits. The key is the long view.

At the same time, the “buzz” is part of what is addictive about the Happening. I have talked to so many people who describe just *dying* to get back to their computer to see what the Happening had pushed to the top of Recent Changes. That excitement is a powerful tool, and we want to preserve it in some fashion.

Hmmmmm.

Anyway, lot’s to think about. Thanks to Frances for starting the conversation.