March 11th, 2007
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!
November 29th, 2004
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)
August 27th, 2003
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.
July 2nd, 2003
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.
Read the rest of this entry »
November 1st, 2002
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.