Laughing Meme » process

That Yak Won’t Sing

Kellan — Mon, 12 Mar 2007 01:28:47 +0000

Enough frisbee, need to get a little work done this weekend. Need a good coffee shop with wifi and power on a Sunday.

Hmmm, really what I need to do is to finally get around to setting up a San Francisco WifiMug.

Which reminds me that I’m kind of unhappy with the current state of the WifiMug codebase (and it’s showing its age a bit, pre-Web 2.0!), guess I should research available Rails wiki software.

Though what I really should do is whip out that Wiki-meets-structured-data-creation-PlacesWiki I’ve been meaning to write.

But first I want to do a comprehensive survey of alternative wiki markups, the space has really fractured. Stikkit is doing good things with natural mark up, while Semantic MediaWiki steamrolls its way through the expressiveness sweet spot, and Google Code wiki has some interesting stuff going on.

But, um, um, um, I should write a new web browser and search engine to research wikis! Yeah, thats the ticket!

Camera-Ready Copy and the Social Denial-of-Service Attack

Kellan — Tue, 22 Nov 2005 02:26:00 +0000

“If you scan the list and can’t spot the sociopath, it’s you.”

What does “pace” mean, anyway?

Kellan — Wed, 26 Jan 2005 04:46:25 +0000

Note to self, do not invent new (latinate) words while trying to run a transparent process.

Growing old gracefully

Kellan — Tue, 30 Nov 2004 03:25:36 +0000

Phil Klein asked an interesting question on the Riders list today.

What are your ideas about how to plan for long life and best futures for your work? Do you use or know of any methodologies that help you shepherd projects into longer life?

In particular has anyone done any work on how you manage wikis and other sorts collaborative spaces (open publishing newswires perhaps) over long life cycles with various levels of engagement (initial, active, ongoing, or archival)

Joel Test for Web Development

Kellan — Tue, 05 Oct 2004 05:23:58 +0000

A port to the web of Joel’s strongly held opinions on software development. (we’re a 2.5)

When we say “process”

Kellan — Wed, 27 Aug 2003 19:39:10 +0000

Process is an embedded reaction to prior stupidity. When I was CTO of a web design firm, I noticed in staff meetings that we only ever talked about process when we were avoiding talking about people. – Clay Shirky

In IMC we talk about process constantly.

Due Process

Kellan — Wed, 02 Jul 2003 09:21:00 +0000

The Echo project switched gears tonight, and in doing so moved into deep water. You see tonight was the night when people started producing Echo feeds. That is the sort of concrete results people like to see, the sort of thing that can trigger a cascade. And it spotlights the Echo projects one serious short coming.

SocioTechnical

For me, the promise of a next generation RSS was not a technical one, but a social one. RSS 1.0’s failure was not that it included a few arbitrary tags (most XML formats do, and most people ignore them), but that it failed to create structures that encouraged growth and development. It had a few things going for it: a mailing list with public archives, a working group with a published decision making process, and a commitment to viewing the format as a public standard. What it failed to do was continue to refine its web presence; adding clarifications to the spec, and building easy entry points for new developers. (the constant feeling of being under siege probably didn’t help, and eventually discouraged early community leaders) So Echo was a chance to do what RSS 1.0 did right, while correcting where it went wrong. An act of social engineering.

Something Different

However there are a few traits to Echo project to date which are different then RSS 1.0, or almost any other project like it. Two key ones come to mind.

No mailing list
Incredible speed of convergence

Instead of a mailing list there is the wiki, but perhaps more importantly there is ongoing conversation scattered over blogspace; a conversational circuit familiar to those who have trudge after what Phil called the Semipermanent Floating RSS Argument but totally opaque to most. Some people find the wiki style of collaboration exhilarating, many find it frustrating. The very web centric nature of this conversation to date has been fascinating, but it has also acted to be exclude a large swathe of the population. A population who have been very active in related project, and in the roots of this one. A number of people have state that they are unable to participate because the conversation is purely web-based, more has simply slipped away.

The other factor which has been incredible (and a bit alarming) is how fast it pulled together. Arguably this is because the work had already been done. Everybody knew what the new format was supposed to look like, the project was just to clarify a few details, and rename it. Actually it turned out that there was a fair amount of debate on the wiki about how to do things, even among the small group who showed up, and yet still the convergence has happened blindingly quickly. (Some have suggested there is a story there still to be told, but I wouldn’t know.) Progress is good, concrete results are good, the maxim of open source development is “release early, release often”, so what is the problem? Well combine a fevered working pace, with a difficult to penetrate discussion space and the barrier to entry gets pretty high.

Haunting Echoes

And something else. This rapid, ad-hoc process reminds me of something, something I had hoped Echo would get away from. It reminds me of the development process for the Userland branch of RSS.

Well Formed, and Whither?

We now have some idea about what a “Well Formed Weblog” looks like. I think the next round of work for the Echo project should not be about nailing down the details of the format, and it certainly shouldn’t be encouraging a thousand Echo feeds to bloom (not that anyone is [or has to]). The next round of work should be sitting down and laying out what a well formed working group looks like.

Otherwise all that has been accomplished is changing some names, and perhaps changing who has the power, but an opportunity to create something more interesting and more open will have been missed, and the chance to tap the insight of the larger community will be lossed. In political organizing there is a word for what we have on our hands, we call it a Tyranny of Structurelessness.

Process & Collaboration

Kellan — Fri, 01 Nov 2002 15:16:00 +0000

Kendall’s latest, Community and Specifications includes

Megginson’s Four Laws of writing successful specs:

Simplicity succeeds
Process is poison
Code first, then specify
Almost every new spec fails anyway

(as the author of SAX presumably he knows of what he speaks)

In a similar vein, the David Clark quote I had as my sig for years (and am thinking of reviving)

“we reject kings, presidents and voting. we believe in rough consensus and running code.”

Been struggling with this of late, particularily in online organizing which exagerates communication problems; walking the line between enough process to stay transparent, and enough flexibility to stay open.