Tags:
create new tag
, view all tags

Asynchronous Conversation Plugin

My idea of a great TWikiApplication is one that does a mash up of existing code to produce radically useful collaboration.

Concept

This plugin provides comprehension & reporting tools for asynchronous conversations that take place in TWiki. I have observed that as conversations develop in TWiki they usually spread out from the first topic and then weave back and forth over time through various topics. The AsynchronousConversationPlugin caters to this natural flow of a conversation by tracking a conversation as it flows naturally from one topic and back again.

Comprehension tools allow for an after the fact reader to start at the beginning or at any node of various criteria such as date, author, topic, conversation name, tag, etc. and follow it through its various phases, possibly with a toolbar.

Reporting tools provide graphs and reports for feedback information.

Management tools include enhancements such as joining MeetingMinutes with the ActionTrackerPlugin and / or VotePlugin to allow for ProjectManagementWithTWiki. Conversation Management Tools are also used to track a dialog through it's various phases: initiation, discussion, vote, decision, implementation, review, closure.

Ingredients

This idea is a MashUp of the following functionality that already exists :

The Mashup

Each new conversation is started with the comment plugin and recives a unique Conversation ID. The comment plugin automatically carries this Conversation ID forward in time , regardless of the TWikiTopic. A given conversation can go through various phases.

With conversation tracking turned on for the web, all conversations are automatically tracked with a unique Conversation ID (perhaps including also a Parent Conversation ID). A mapping table allows for optional Conversation Name Resolution for important conversations that could then be referenced in future conversations by name. Conversations could then be referred to either by name or number.

When starting a conversation, the %CONVERSATION% variable can be invoked with various optional attributes, thus allowing customization of the conversation from the start. For exampe:

%CONVERSATION{"name="WhatIfConversation" goal="decision" priority="medium" project="NewMelliniumProject" relevance="very relevant"}%

Sample Report (Brainstorm)

Brainstormed_Asynchronous_Conversation_Plugin_Report.png

Contributors: -- KeithHelfrich - 27 Nov 2006

Comments and Discussion

Eventually, I'm seeing the wiki becoming a replacement for email within cohesive groups. The email replacement becomes especially attractive as RSS feeds and wiki-incorporated chat also become available.

I'm liking that revision control allows project managers and executives to, when necessary, look back on conversations they were not present for at the time (in order to understand decisions that were made). And similary, I'm liking the same ability for auditiors, judges and jurors to look back on the conversations of corporate managers and public officers when the need arisises.

By building an asynchronous communication platform, we create the tools upon which OpenSourceTeamwork can thrive. By participating in the Team web, and knowing that all asynchronous conversations held there are open and subject to public review, the quality of collaboration by each team member and the quality of the teamwork overall strenghtens. This happens for the same reasons that the quality of code is strengthened by public review.

If twiki is to become the premier collaboration platform, then the way to do that is to overtake the current #1 by preying on it's weaknesses. And happily I think that twiki is uniquely positioned to do that! smile My concept behind this plugin is to develop a KillerApp that radically improves aynchronous communication and finally puts email, the current and "unfit" ruler of collaboration, in its place.

-- KeithHelfrich - 28 Nov 2006

Interesting idea. I have often thought that TWiki topics (and lots of HTML pages in general) are too large chunks: too many concepts on one page to track/retrieve useful information. The size of small blog posts often fits better.

Considering everything in a topic can be edited, how would Conversation IDs (or Idea IDs) get copied over, or generally be referred to? Would a written reference like #CID123456 suffice? When tracking, how would you define the scope of a Conversation? Would multiple Conversations in one topic collide?

-- ArthurClemens - 29 Nov 2006

Somewhat related: PurpleWiki with PurpleNumbers.

-- PeterThoeny - 29 Nov 2006

Arthur, I agree. The tracking technique I'm not certain about yet. But with everything from cookies to web bugs to transparent GIFs and session IDs, I can't imagine that it would be difficult to actually track something in web 2.0 that actually wants to be tracked. I suppose that's what makes this one into a brainstorming topic. smile

What I've been stewing on recently that with TWiki, we've got these entities whose relationship is very well known:

  • TOPICS
  • COMMENTS

But the gaping problem is that their third hand is systematically absent from the equation:

  • CONVERSATION

A topic is not the conversation (because a single conversation often spans many topics). This plugin has three goals :

  1. Comprehension tools to help the latecoming reader to navigate the conversation at any node of various criteria in order to catch up
  2. Reporting tools to give management a graphical intuition about what asychronous conversations are taking place within the organization at this time and what their various phases of development are.
  3. Management tools such as the facilitation of progress through the various phases of a conversation from initiation to discussion, vote, decision, implementation, review, closure, hindsight, etc.

Peter, I think the PurpleNumbers are very appropriate. Imagine, for example, if every comment from the CommentPlugin were to be treated like a paragraph in the PurpleWiki. The comments then become distinct objects and sorting / navigating them based on attributes such as date, author, and the elusive Conversation ID = #CID123456 becomes a matter of managing the relationships. I bite my tongue in TWiki land, but I wonder if a relational database wouldn't do the trick ?

Again, just brainstorms here. In the end, I'm not a programmer. Just a forward thinking, tech user with an eye for what could be done. If someone sees the way, do tell. I might just hire a programmer.

-- KeithHelfrich - 01 Dec 2006

Creating the reports would be possible by 1) treating every comment as a piece of data and 2) using TWiki support for pivot tables

-- KeithHelfrich - 22 Feb 2007

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Brainstormed_Asynchronous_Conversation_Plugin_Report.png r1 manage 59.3 K 2006-11-27 - 05:16 KeithHelfrich Brainstormed Asynchronous Conversation Plugin Report
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2007-02-22 - KeithHelfrich
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.