Email Discussion Beside Wiki

I think Wiki For CollaborationWare is hugely important. It's the right HyperText repository to document ideas/issues, their resolutions/changes, and track progress.

(Key note: the Context I'm interested in is a smallish team trying to accomplish something. And there's some sort of culture/force - typically co-employment and the related need to generate sufficient profit to stay that way - driving coherence.)

But I think Wiki is pretty bad for Group Discussion. (This is typically called ThreadMode, as opposed to Document Mode). Why? Because of the challenges of Tracking Wiki Changes.

• Almost any team includes people who will not check Wiki RecentChanges every half hour, but will be in their EMail client constantly.

• It's difficult in a largish wiki to track the subset of activity of relevance to you.

  • Some wikis support EMail subscription to individual pages, but this seems a bit clunky to me.

• Within a given wiki page, any progress that involves refactoring the page (vs just having a sequence of Appended comments) will confuse people who aren't reviewing the page every hour.

So I think another mode of Group Discussion is necessary.

For the moment, I think EMail is the way to go. Maybe that's because it continues to be the primary place where people look for notifications. Maybe once there's a Universal Inbox bringing together multiple modes of messaging into a single place, that won't be so much the case. Then we can use Node Web. :)

(Some people like to integrate other media like EMail and IRC with Wiki. Because Summarizing Is Necessary, I think that "raw flows" of content, if posted to Wiki, should be in a separate space linked as Sister Sites, so that BackLinks and search results aren't overwhelmed with unsummarized stuff.)

So, given the use of EMail for Group Discussion alongside a Wiki For CollaborationWare, what's wrong with vanilla EMail? Can the technology be tweaked a bit to make it more effective?

How I often use vanilla EMail with a TeamWiki

Simple rules

• use WikiWord-s not Free Link-s in my TeamWiki
• use WikiWords in EMail even though they're not linked - they become an implicit link (plus I can search my personal email archives better).
• if a couple key TeamWiki pages are extremely helpful as reference, then include those links in the email. Don't overdo it, don't feel the need to turn every WikiWord into a link.
• on the other hand, sometimes it easiest to just quote a wiki page by Drag And Drop into an HtmlEmail, and that's ok.

Some random notes for later consideration

Problems with plain old EMail (subtext: are these problems bad enough to bother with more infrastructure? Buy Build Avoid)

• a thread that involves a lot of subpoints and a lot of back-and-forth becomes very hard to read/follow/refactor.

• Wiki Name-s don't get linked

  • this would require the message to get rendered to HtmlEmail, which some people get crazy about

    • should we force them? a decent mail client can turn off JavaScript and Java, so I'm not as concerned about mail-content viruses or annoyances

      • and many mailers send (optionally) both plaintext and HTML versions of messages - can't their readers recognize just the plaintext version? see Blue Oxen thread

    • do HTML messages have problems in Email List archives? Shouldn't.

    • or maybe you could just stick the wiki page URL right after its name in the body of the plaintext message?

      • I don't know whether that would screw up wrapping of plaintext email.

      • and it's pretty ugly

      • and it's nice to be able to hide ugly URL-s when cross-referencing messages (which happens lots more with Purple Numbers in use)

    • my conclusion: yes, assume HTML email is OK for most workgroups.

• some people think it's important to have an archive.

  • Is that just for complex searching, since EMail clients do such a bad job?

  • Also for cross-referencing "the record"

    • but isn't quoting during the thread and referring to the conclusion summarized in the wiki after-the-fact sufficient??? also note that

      • an email archive is just an archive of email, not of all conversation, but people forget that.

      • a team that's accomplishing things is moving in time

        • there's less likelihood of rehashing old stuff, than in a public talking-about-stuff environment

        • when things do come up again, it's often the case that the context has changed so much that the full detail of the old email thread isn't very relevant anymore. (And again, the wiki should contain key decisions and why they were made. And of course people do still have their own email archives...)

• people don't think, write, or read clearly. Can tech do anything about that?

  • maybe software that encourages OutLining and Structured Writing helps a bit.

  • maybe software that supports a refactoring of someone else's comment would help (Annotation Systems?) (hmm, will they like that?)

    • how decide (who decides?) whether refactored comment is better for responding to than the original? How communicate that decision, so that responses don't end up forked?

  • Disputation Arena-s?

Use a single Email List for the whole team?

• that makes it harder for individuals to ignore the issues that don't require their attention.

• it can also encourage the over-involvement of certain busybodies. But maybe that's not a technical problem. But the technology exacerbates a social problem.

Don't use the Email List for distribution, but archive all messages to a single archive.

• how? try and get everyone to remember to cc a certain address? patch SMTP server?

• how do you keep certain messages from getting archived? (Personal/private and corporate/confidential)

  • cc an archive address to get a message included.

  • require authentication to read archives - tie to recipient list of original message

    • have to worry about information even in list of message Subjects

    • also have to worry about Search Engine interface: 'find Bob and layoff'

    • maybe have 2nd archive for "senior" team for super-confidential stuff?

• this approach means you have an archive but no message-parsing proxy to do Wiki Name and Purple Numbers rendering.

Nosy List feature like Round Up?

WikiMail? WikiProxy? Purple Numbers?

Good Blue Oxen thread about Purple Numbers in email, also discusses using Wiki SmartAscii for body vs HTML.

Blue Oxen also makes good use of the List-Archive header field for each message's archive URL - it shows up nicely at the bottom (in Mozilla, don't know if MsOutlook supports it), and when you Reply it disappears.

Blue Oxen:ChilledNotFrozen

Where in the flow insert a proxy: which is shared? (with a "closed" team, there could still be a Free Agent contractor involved, or an offsite Customer)

• SMTP

• IMAP

• listserv: Would probably want to work with MailMan, since it's Python-based and runs at IMeme.

• Fat Client proxy (for which protocol?) (Zoe)

I started a thread at Blue Oxen about this. We never came up with a good design/solution.

Dec'2012: the Community Wiki folks are having a discussion on FaceBook as to whether the combo of FaceBook plus Wiki hits a sweet spot, esp for Group Forming (where drawing in non-techies who won't subscribe to an Email List, follow RSS, etc.).