• Email Discussion Beside Wiki

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

(Key note: the Con Text 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 Wi Ki is pretty bad for Group Discussion. (This is typically called Thread Mode, as opposed to Document Mode). Why? Because of the challenges of Tracking Wiki Changes.

• Almost any team includes people who will not check Wi Ki Recent Changes 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 Wi Ki. Because Summarizing Is Necessary, I think that "raw flows" of content, if posted to Wi Ki, should be in a separate space linked as Sister Sites, so that Back Links and search results aren't overwhelmed with unsummarized stuff.)

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

<hr>

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 Html Email, which some people get crazy about

    • should we force them? a decent mail client can turn off Java Script 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 [[http://collab.blueoxen.net/forums/tools-yak/2003-07/threads.html#00065

|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 Out Lining 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?

Wiki Mail? Wiki Proxy? Purple Numbers?

Good Blue Oxen thread about Purple Numbers in email, also discusses using Wiki Smart Ascii 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 Moz Illa, don't know if Ms Outlook supports it), and when you Reply it disappears.

BlueOxen: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 Mail Man, since it's Py Thon-based and runs at IMeme.

• Fat Client proxy (for which protocol?) (Zo E)

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

<hr>