Mailing List Etiquette and Experimentation

I’ve been an e-mail user for over 10 years, and a mailing list and USENET user for just about as long, so I have strong beliefs about proper mailing list etiquette. That puts me in an interesting position as a participant in the Blue Oxen Collaboratories. On the one hand, these collaboratories are supposed to be shining examples of high-performance collaboration. On the other hand, they’re also supposed to be testbeds for experimentation and coevolution.    (8K)

Sometimes, people use the lists in ways that conflict with my inner sense of etiquette. However, etiquette is a form of social constraint, and if we forget why we find these constraints valuable, our sense of etiquette can impede collaboration.    (8L)

The collaboratories are a perfect place to have metadiscussions about this sort of behavior as it happens, but unfortunately, it’s hard for me to participate or initiate those discussions. Because of my position at Blue Oxen Associates, my commentary can be perceived as law rather than opinion, and I don’t want that to be the case.    (8M)

That, of course, is the reason for this blog — for me to WhineInPrivate in public. Which leads me to today’s topic.    (8N)

Cross-Posting    (8O)

The impetus for this entry was a discussion this morning with Andrius Kulikauskas, who called me all the way from Lithuania. Andrius founded the Minciu Sodas laboratory, which is similar in spirit to Blue Oxen Associates, and he actively participates in our collaboratories.    (8P)

One thing that Andrius does often is cross-post across different forums and mailing lists. I’m not a big fan of cross-posting, but I think there are times when it’s appropriate. The problems are:    (8Q)

  • List participation is often restricted to participants, largely as a way to avoid spam. As a result, people will not necessarily see responses to cross-posts, and it can result in stilted and confusing discussion.    (8R)
  • There is a force at work within effective communities: Know Your Audience. People behave differently depending on their audience, as well they should. You may know the audiences of the lists to which you are cross-posting, but the different members of each list may not, and that will affect how or whether they respond.    (8S)

Andrius and I discussed this a bit over the phone. One of his rationales for cross-posting is that it builds awareness of other communities, and that it encourages interconnectedness. I definitely believe in the former, but I’m not so sure about the latter. Simply knowing that a community exists certainly enables interconnectedness at some level, but cross-posting could also discourage interconnectedness. If there is no Shared Language on the different lists, cross-posts can unintentionally lead to further balkanization of communities.    (8T)

I’m not a big fan of cross-posting, but I tolerate it, and for good reason. When Andrius did it, it forced me to think very hard about why I disliked it. That helped me understand the reason for my feelings, and it also helped me think through some half-baked ideas. For example, when you consider the benefits of cross-posting, it’s clear that the technical balkanization of mailing lists caused by restricting participation to subscribers can be a very bad thing. One advantage with USENET newsgroups or web-based forums is that you don’t have this balkanization. On the other hand, these forums are susceptible to spam. I’m certain there is a technical solution to this problem, although I don’t know what it is yet.    (8U)

Off-Topic Postings    (8V)

A great example of where etiquette can be overly enforced is off-topic postings. I’ve noticed that on some lists, moderators are tyrannical about keeping discussion on-topic. While I understand the reasoning, being too extreme about this can do more harm than good. The nature of online spaces is different from face-to-face spaces, and the former is a more tolerant space for divergent ramblings than the latter. I wrote some thoughts on this in an earlier entry.    (8W)

Another reason for tolerating some off-topic discussions is the Water Cooler pattern. Communities are more effective when people have shared experiences, and informal socializing is a great way for identifying or creating these experiences. Several months ago, there was a discussion about local restaurants on the San Francisco Perl User Group mailing list. This clearly had no relevance to Perl, but it was very interesting, and no one complained. In fact, the original poster asked for recommendations off-list, and several people e-mailed him asking to post the responses on-list instead.    (8X)

PurpleWiki v0.9 Released

PurpleWiki v0.9 is now available. Chris Dent‘s announcement covers the basics. A few words on how we got here, and where we’re going.    (83)

The Wiki Experiment    (84)

When we launched Blue Oxen Associates last December, we made Wikis a core part of our infrastructure. We had two reasons for choosing Wikis. The first was practical. We needed a system for sharing documents and collaborative authoring, and Wikis fit the bill quite nicely.    (85)

The second reason was more philosophical. We wanted a knowledge management system like Doug Engelbart‘s Open Hyperdocument System (OHS), and felt that Wikis already resembled the OHS in many ways. It was immediately usable and useful, while also offering the perfect platform for coevolution.    (86)

PurpleWiki fulfills the following OHS requirements:    (87)

  • Backlinks. This is a core feature of all Wikis, but also one of its most underutilized. In a future version of PurpleWiki, we will create an open API to its Backlink engine, so that other applications (such as blogs) may use it.    (88)
  • Granular Addressability. PurpleWiki‘s site-wide, automatic Purple Number management had the additional benefit of enabling us to quickly experiment and evolve the feature. Node IDs are now document-independent, which has improved usability and enabled features like Transclusions.    (89)
  • Link Types. We’ve added a syntax for specifying link types, and have implemented our first new link type: Transclusions.    (8A)
  • View Control. We can easily add new or customize existing output formats, thanks to PurpleWiki‘s modular architecture. More importantly, we can implement dynamic views, such as a collapsible outline view, of any document on PurpleWiki.    (8B)

PurpleWiki‘s most visible feature is Purple Numbers, but its most important feature is its data architecture. In general, Wikis view the world as a graph of linked documents. PurpleWiki views the world as a graph of linked documents with a unified data model. The data model is sufficiently general and simple to apply to any kind of document. When you use this data model in other applications, you automatically inherit PurpleWiki‘s features. Integrating PurpleWiki with blogs was a piece of cake as a result, and we’ve only begun to explore the ramifications.    (8C)

Next Steps    (8D)

Our roadmap lists several enterprise features we plan on implementing: templates, pluggable database back-ends, mod_perl controller, etc. I consider these important, but relatively mundane. Blue Oxen Associates isn’t in the business of software development; we’re implementing these features because we need them.    (8E)

Blue Oxen Associates is in the business of research and improvement, and of facilitating coevolution. PurpleWiki is an amazing platform for this. One of Chris’s pet projects is to create universal ID space for nodes, possibly based on handles. Think of this as persistent URIs for nodes. Among other things, this will enable us to support Transclusions of content from other sites, not just the site on which PurpleWiki is installed.    (8F)

My long-term interests lie in three areas: the aforementioned open Backlink engine, Wiki page types, and Wiki namespaces. I’ll discuss the latter a bit here.    (8G)

One of the reasons I dislike TWiki is its notion of “webs.” You can partition your Wiki into multiple webs, and each web is contained in its own namespace. The problem with this is that it encourages people to balkanize their Wiki content. That, in my opinion, runs counter to the spirit of Wikis. Early balkanization prevents evolution.    (8H)

Several months ago, Richard Gabriel passed along some insight he had learned from Ward Cunningham: In computer science, you want to keep namespaces separate. With Wikis, you want namespaces to clash. Ward’s idea for SisterSites is one way to create namespace clash. This idea could be taken a step further by allowing site administrators to establish a system of namespace resolution. For example, if a certain page doesn’t exist on a local namespace, the Wiki would search another namespace for that page. If it existed there, the Wiki would simply take the user to that page.    (8I)

A Brief History of Purple Numbers

A few weeks ago, Chris Dent posted a brief history of Purple Numbers, noting, “This is likely full of errors as the story as I’ve heard it is incomplete and I was unable to check some things because the network path to California was busted while I was writing.” His account is pretty good, but there are a few holes here and there. Most of my clarifications are nitpicky. In case you, my dear readers, haven’t realized it yet, I am very anal.    (7W)

Chris differentiates NLS from the mouse, hypertext, GUIs, and so forth. NLS was actually the totality of all of these things. Chris also says that NLS had a “graph based document storage model.” This is somewhat of an ambiguous description, and depending on how you read it, is not strictly true. Finally, NLS did not have transclusions, although its architecture could easily have supported them.    (7X)

In between NLS and the first appearance of Purple Numbers on the Bootstrap Institute’s web site, there was a graphical Augment client written in Smalltalk. The first Augment PC client was MS-DOS-based. Doug still uses this! In the early 1990s, a contractor wrote a GUI client for Windows, which displayed statement IDs (what we call node IDs) in purple. According to Doug, the choice of color was either his daughter’s, Christina, or the author of the client. In any case, this is why Purple Numbers are purple.    (7Y)

Bootstrap Institute first used Purple Numbers to display structural location numbers (what we call hierarchical IDs) for Augment documents converted to HTML. Soon afterwards, Frode Heglund suggested making the numbers a live link, so that it would be easy to copy and paste the node’s address.    (7Z)

On January 31, 2001, I released the first version of Purple, which was a collection of Perl and XSLT scripts for adding node and hierarchical IDs to documents and generating HTML with Purple Numbers. I believe my most important contribution at the time was recognizing that node IDs were more useful in a Web context, where documents were largely dynamic, than hierarchical IDs. On April 24, 2001, Murray Altheim released plink, a Java program similar to Purple, except that it worked on XHTML files.    (80)

My OHS Launch Community experiment (June 15 – November 9, 2001) proved to be a fruitful time for Purple Numbers. Murray and I agreed on a standard addressing scheme for Purple Numbers. I implemented a MHonArc filter for adding Purple Numbers to and extracting Backlinks from mailing list archives, and tool that generated HTML with Purple Numbers from Quest Map files.    (81)

I also started thinking about PurpleWiki for the first time, and hacked a first version based on TWiki. This experience gave me a better understanding of the right way to implement PurpleWiki, and it also gave me a healthy distaste for TWiki. When Chris joined Blue Oxen Associates, we made PurpleWiki a priority, and the rest is history. Chris’s account from there is pretty complete.    (82)

Revising Blog Entries

Ross Mayfield observes that, when there are sudden news events, bloggers continually revise the same post rather than make new post after new post. He notes that this is very Wiki-like behavior and is not how blogs are supposed to be used, citing Dave Winer’s essay, “What Makes a Weblog A Weblog?”.    (7U)

This all goes back to Danny Ayers‘s recent question about dynamic content in Wiki pages, and my subsequent response.    (7V)