Eugene Eric Kim wrote:
>
> I think this is a good paper that summarizes a lot of important
> concepts. I also agree with the overall strategic approach.
> Targeting standards organizations is an excellent choice -- it gives
> you a well-defined, concrete audience that is dealing with a very
> wicked problem of collaboration, both synchronous and asynchronous. I
> also think there's a good market opportunity here. OASIS is an
> excellent group that exploits this opportunity using crude tools --
> mailing lists -- and excellent process. If OASIS were to offer better
> tools than mailing lists, I think it would be an even more compelling
> organization than it already is.
> ....
> As for building an asynchronous IBIS tool, I would like to argue
> strongly for building a tool that facilitates IBIS facilitation of
> asynchronous discussions, rather than expecting participants to
> structure the discussion themselves. Jeff Conklin has cited many
> reasons for why he thinks that asynchronous IBIS tools will not work,
> and he has real experience supporting this contention.
>
Thanks for the comments, Eugene, and for helping me realize
that I need to focus the presentation on the intended
customers (and do the appropriate information gathering and
requirements analysis). (01)
I am in absolute agreement that the system needs to enable
facilitation, and recently came up with an idea for how that
might work. (Then I got sick for about a week. I'm still
recovering, but I'll give it a go here.) (02)
Basically, I saw 6 "story points" that would support
collaboration in a Wiki+Email environment:
1) "Reply" to (comment on) a purplized paragraph.
This suggests a [comment] button adjacent to each p#.
(There would also be one at the bottom of the page
for comments on the whole thing.) (03)
2) Record who made the post.
Possible in a wiki-framework, since everyone is logged in.
And since each ID is a wiki-word, each ID can link to a
page with a picture. (Future client: retrieve and display
thumbnails automatically.) (04)
3) View the resulting document in a normal browser
So documents can be reviewed and edited by anyone, as with
Wiki. (That implies two kinds of link types. One for
transclusions, which are copied to create the HTML
page, and one for normal links.) (05)
4) View it in an outline browser
This browser might view the XML form, and it might have
the "comment" operation on a right-click menu, instead of
having it be part of the page. It might also do difference
highlighting. Basically, this is the place to go wild. (06)
5) Notify readers
A single document-level [commit] button is needed to send
all comments (or changes) at one time. The interesting
thing about it is that you can say anything you want, and
be able to go back and edit your comments before you commit
them. (07)
6) Reorganize, Relink, Subsume
The crux. This operation may be limited to the facilitator,
or the "spec lead" (document owner). But it is crucial.
It must be possible to insert a new node and subsume
existing nodes under it, with a link to a page containing
those nodes. That way, material is never deleted, but
remains accessible as background information. (08)
Some or all of these features may already be available in
NexistWiki, Compendium, or Elephant. I look forward to finding
out which ones are available, where. (09)
That last operation, in particular, might well be sufficient
both for a spec collaboration and for an IBIS discussion. When
a new issue or alternative is raised, deep in some discussion,
it can be effectively "promoted" to a higher level -- and that
is the one critical feature that email systems totally lack. (010)
The difference between that operation and normal linking is that,
with normal linking, the material remains where it was. But
when subsuming, the material is removed from the normal flow of
the document, and can only be seen by traversing a non-transcluding
link to get to it. As a result, the discussion can contract and
simplify over time, as well as expand and grow in complexity. (011)
Perhaps my biggest realization here was that an argument, like
a document, can be "structured" in the sense of having links and
sectional organization, without being "labeled" or "categorized"
in an IBIS sense. (012)
Some recent discussions led to that realization. One was in this
forum, on the subject of what topics to discuss to evaluate
different collaboration tools. Another was on the subject of
Iraq on the ba-unrev list. And there was the consideration of the
collaboration tool for spec-development, itself. A few things
became apparent: (013)
a) The concept of issues, alternatives, and arguments (pro and
con) seems like a good idea, when considered in the
abstract. But darned if they don't turn out to be insufficient
in the real world. (014)
For example, the question "what topics should we discuss using
different collaboration tools in order to evaluate them"
quickly bifurcated down two different paths:
* What characteristics define a "good" topic for discussion?
* Which topics meet those characteristics. (015)
As the thinking about characteristics changed, I found myself
advocating a different set of topics. There were now "sets of
characteristics" and "sets of topics" to consider, with links
between the sets. I saw no good way to map that structure into
"issues, alternatives, and arguments". (016)
b) When looking at the needs of spec developers, it became clear
that there is a pretty circumscribed set of ways to address
an "issue" (a spec requirement) -- incorporate it, allow for
extension to address it, provide componentry necessary to
build it, defer it, rate it as "nice, but not necessary", or
reject it, or ignore it. But if each issue is a requirement,
then each proposal (alternative) addresses each issue in the
set in one of those ways. There is a very straight forward
structure here that can be mapped into a table, but it doesn't
seem to fit the IBIS pattern. (017)
c) Further, while I may claim that proposal B addresses issue I
by providing for extension, someone else may argue that B
actually precludes I, for some reason. We now have different
claims for the relationship between an issue and an
alternative, which isn't part of the IBIS system. (018)
d) Finally, in the far-ranging "what about Iraq" discussion, it
became apparent that a more appropriate analogy for the
problem was really a chess game, where different people
analyze the position differently, and suggest different
strategies, rather than a philosophical debate, where the
issue/argument structure might more readily apply. (019)
However, in all of these discussions, there was definitely a sense
of "structure", in that some comments replied to others (or to
collections of other comments). And there was a terrific summary
provided by Benja that, unfortunately, had to remain buried down
in the depths of the discussion, rather than being raised to
a prominent position as an "umbrella" for it, where it belonged. (020)
So all of these factors led to the realization that while we
need better tools for structuring (and restructuring) a discussion,
we probably *don't* need to worry about labels and classifications
-- and that a well designed purpleWiki+email system might do the
job. (021)
--
This message is archived at: (022)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=3E726282.F89BE670@sun.com (023)
|