Subject: Next tool steps to support collaborative discussion (01)
Eric, (02)
No argument. Solve collaboration with some degree of persistence and a good
way to refactor, and we have a real start. (03)
Given a persistent knowledge store, we can study ways of adding intelligence
to it to improve it. (04)
Then we can see if there are ways of capturing more of the intelligence that
we decide is useful at the point of discussion or as a part of refactoring. (05)
Off the top of my head I would recommend: (06)
* Use wiki text in plain text messages.
* Relax the wiki syntax to allow lists to be indented for appearance. Manage
multiple line paragraphs in addition to the current line == paragraph model.
* Process the purple numbers before posting the emails to the list.
* For any situation in which email headers are inadequate, add elements to
the wiki format to handle better subjects, better reply to, whatever.
* Possibly support a body element to provide a subject for the email even
though it is still in a thread, as I have done here.
* Support a shorter URL for messages to clean up quoting (this is for
appearance only). (07)
Imo, this would provide us with a plain text archive that could be processed
as desired for indexes, etc. By using special index nodes to root a
discussion, we could migrate summaries to the top by simply flagging them
with a new position in the thread. (08)
Given the same sorts as we have now in the archive (thread, author, date),
and possibly a way to do one or two more for summaries or other ideas, we
could do some very interesting things with collaboration. (09)
Given an indented thread listing of links and maybe specific subject lines
within the thread, I could organize the entire thing into a local outliner
and refactor as I please. (010)
I like the idea -- always have. (011)
What are your thoughts on the next step for a collaborative discussion tool
based around email, a persistent archive, wiki, and purple numbers, which is
what we seem to have readily at hand.? (012)
Thanks, (013)
Garold (Gary) L. Johnson (014)
-----Original Message-----
From: Eric Armstrong [mailto:eric.armstrong@sun.com]
Sent: Friday, March 21, 2003 3:37 PM
To: yak@collab.blueoxen.net
Subject: [yak@collab] Re: Starting Point for Collab Tool: STORY POINTS (015)
Ah. Yes. Totally agree. I see categorization with some
sort of hierarchical taxonomy and/or topic map network
as the next critical step in moving the tool towards a
knowledge-management system. (016)
I emphasize that it is the *second* step, however. Early
on, I thought it was critical to the collaboration problem.
Now, I'm thinking that it isn't. (017)
I see remote collaboration as the first problem that needs
to be solved, so that bigger and better systems can be
evolved, extended, or designed. (018)
"Garold (Gary) L. Johnson" wrote:
>
> Eric Armstrong wrote:
>
> * I'm not sure what you mean here. Do mean the ability to define arbitrary
> > categories (aka classes), and assign them to purplized nodes? If so, I
> > grant that it would be useful, and I'd love to see it. (I think that's
> > what Peter was alluding to when he mentioned reorganizing at a meta
> > level.) But I've reached the conclusion that a well-structured
> > discussion can be carried on without them.
>
> For discussions, I agree, but discussions are not all there is in the
world.
>
> I want to be able to use the same system to organize meeting notes,
> documents that I need to study and my notes on them, project analysis,
> software design information, ... and nearly any other sort of information
> that I need to find again.
>
> Subjects (Topic Maps) help for that. I see topic maps as essentially an
> outline on which to hang information. While using outliners with the
subject
> / article model, I often find that it would be convenient to have some
sort
> of outline separate from the information, and that is what subjects are
for
> me.
>
> One feature I always want in an outliner is "cloning", the ability to have
> the same record in more than one place. I see a good Topic Map system as
an
> outliner where every node is a pointer, and hence a single node can be in
as
> many places at once as is convenient.
>
> In some paper filing systems that work this way, the process is to search
> for a folder by how you remember it, and if you don't find it where you
> think it should be, mark the spot. When you do find the folder, return to
> any marked spots and insert a reference to the correct folder. This scheme
> works within any linked system.
>
> When followed consistently, information tends to be located by the all of
> the "intuitive" paths, much as happens in human memory.
>
> == Wiki Parents ==
>
> All that is done in such systems is to save the node name used to create
the
> new entry. This provides a singly linked list of ancestors. Some systems
> then support manipulations of the structure. Along with back links and
"see
> also" structures, Wikis become much easier to navigate.
>
> Thanks,
>
> Garold (Gary) L. Johnson
>
> --
> This message is archived at:
>
>
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=MIEJJJFBHJEBDEKGP
HOPMEGHEAAA.dynalt@dynalt.com (019)
--
This message is archived at: (020)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=3E7BA21B.9D271983
@sun.com (021)
--
This message is archived at: (022)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=MIEJJJFBHJEBDEKGPHOPEEJFEAAA.dynalt@dynalt.com (023)
|