From: Eric Armstrong <eric.armstrong@eng.sun.com>
For those who plan to be involved in the development
of the Stage I DKR ala' Adam Cheyer, I'd like to
propose the following introduction to the IBIS method:
This document is brilliant exposition of the IBIS principles.
It is also extremely readable. (It was written by Jeff
Conklin as a manual for using the MapQuest system,
which adds automation to IBIS. More of his papers can
be found at http://www.gdss.com/WP.htm)
Although I've had some difficulty seeing how to apply it
to the broad spectrum of discussions that appear in this
forum and in the colloquium, it appears to be perfectly
suited for system design discussions.
We may be able to carry on a reasonable facsimile of an
IBIS-discussion in email, too. More on that in a moment.
First, I'll give a quick summary of some of IBIS' general
principles.
Some General Principles
-------------------------
Possibly the most useful general principle I got out of the
IBIS discussion was the principle of never supplying
*answers* but instead *alternatives*, and always
under the banner of a *question*.
The goal of the system is to tackle "wicked projects",
which have the interesting characteristic that typically
no one agrees on what the real problem is. (Sound
familiar?)
Especially when disagreements occur, the key, it
appears, is to raise the general question, identify
the named alternatives -- leaving room for *other*
alternatives, and then investigate the alternatives,
secure in the knowledge that one's own pet idea
has been recorded and will receive it's share of
investigation. (Who was it that told me about that
at the colloquium?)
The effect on discourse is remarkable. Instead of
competing for attention to one's view, there tends
to be a more relaxed, cooperative investigation of
the possibilities.
Personally, I have always admired those folks who
seem to be able to manage the stress in a room and
get everyone to think rationally. Frequently, I've been
one of the stressor/stressee's, and have always
marveled at those few precious individuals who
have managed to get me thinking about the problem
from all angles. The IBIS system seems to shed
remarkable insight on how they accomplished that
trick.
IBIS in Email
--------------
To summarize the IBIS system, you have questions,
and proposed answers under them. Under each
proposal you have pros and cons. There are other
information entities, as well. Let's start with these,
for now, and see how a facsimile of the IBIS system
could be replicated in email.
First, we'd have to start by coming up with a convention
for identifying messages. For a start, let's consider
using:
Q: Question
A: Alternative
P: Pro
C: Con
I particular like "A" because it masquerades as an
"answer" (see "The Answer Reflex" in Conklin's
document) when in reality, it is an "alternative".
Since it is a principle of IBIS that you don't put forth
an "A:" without a "Q" to attach it to, creating the "Q:"
entry forces you to state the problem you are trying
to solve, and at the same time provides a place from
which to hang other alternatives. That prevents
discussions from being closed.
[Note: One minor flaw in the system is that a pure
hierarchy is less than convenient for proposing a
solution which solves *multiple* problems. For that,
we need the DKR we are aiming at.]
The second major issue is one of browsing the messages.
I know of one browser (Messenger) that can do the job
effectively, but I'm not sure how others will work.
Netscape Messenger has a terrific thread view that
gives a hierarchical view of messages. Even if you change
the message title, a response shows up under the original
thread. That means we could use the prefixes above to
carry on an IBIS style design discussion. One of the threads
might look like this:
Q: How will we edit the XML structures?
A: An XML-editor applet in Java
P: Easy to do. We have an editor we could modify.
C: Liable to be slow
C: Hard to know when document will be unlocked.
A: Checkout, FTP, edit, and checkin
P: Allows fast editing
P: Lets you use any editor you want
P: XML differencer can find differences
C: Differences are document-centric (last version)
rather than user-centric (last version *I* saw)
C: Eats transmission time
C: Not clear how to handle conflicts
C: WebDAV not ready yet (?)
A: Multi-threaded editor servlet
P: Multiple people can edit same document at once
P: Conflict only occurs when two people access
the same node at the same time
C: A lot more programming
A: Combination of above, one for short term, one
for longer term
...etc...
Each of these statements is subject to challenges, of
course, as explained in the final section of this document.
But like any good design recording device, this structure
keeps track of the alternatives that were considered and
the reasons for rejecting them -- information which can
be invaluable downstream.
The third issue is one of training ourselves. To use the
system effectively, we need to initiate messages with Q:
headings, and change the subject line every time we reply
with alternatives, pros, or cons. If we can do that, it can
work.
Fourth, it must be noted that such a system will generate
MANY more messages than currently. They'll be nicely
organized under threads, but there will be a lot of them.
At a minimum then, perhaps multiple mailing lists are
needed.
[Future: Ideally, the mailing list would be in a hierarchy
that allows me to say "I'm not interested in any detail
below this item's sublist, just let me track the high level
view. Then I could monitor a Q: and the A: entries under
it, but ignore the P: and C: entries until I became interested.
That's a bit down the pike, though.]
Other Information Types
-------------------------
Just to complete the proposal (which may or may not be
viable, given browser preferences) here are some
possible message tags for the other major entries I
gleaned from Conklin's document:
CH: Challenges
SP: Specializes
XP: Expands
N: Note
E: Endorsement
D: Decision
The CH: element would be used for statements like
C: WebDAV not ready yet (?)
CH: Yes it is. You can find one at http:...
The Endorsement and Decision tags are most
interesting, as well. One can envision questions
like:
Q: What should we build for a DKR prototype?
A: Adam Cheyer's Next Steps (NS) proposal
E: Me!
E: Me too!
Q: What should we call the protoype?
A: DKR v 1.0
A: Next Steps (NS)
A. Baby Steps (BS)
...sorry. couldn't resist. :_)
A. Next Step (NS)
--------------------------- ONElist Sponsor ----------------------------
GET A NEXTCARD VISA, in 30 seconds. Get rates as low as 0.0 percent
Intro APR and no hidden fees. Apply NOW.
<a href=" http://clickme.onelist.com/ad/NextcardCreativeCL ">Click Here</a>
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:41 PDT