[unrev-II] Welcome Message for IBIS list

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Sat Jan 29 2000 - 18:56:45 PST


From: Eric Armstrong <eric.armstrong@eng.sun.com>

This is one to file, in case we decide to try an IBIS-style
discussion. If we do, we should up a separate mailing list
for it. This is a draft of a Welcome message for such a
list. (This message is mostly a duplicate of my last message
on the subject, arranged slightly differently and with a
bit more detail.)
-----------------------------------------------------------
Subject: <mailing list name>Welcome! PLEASE READ
Body:
PLEASE READ THIS MESSAGE.

This is an IBIS-style mailing list. For a short, readable introduction
to the IBIS method, please read
  http://www.gdss.com/IBIS.htm

TO USE THIS LIST EFFECTIVELY, you need a mail client that keeps track
of conversation "threads", and the threads must be maintained even
though the subject lines have changed. To do that, use:
   * Netscape Messenger, Threads view
   * ...

    (If you know of any other mail clients that works
     as well, please inform us at mailto:____.)

How to Use this List
---------------------
Here are the "rules of the road" for using this IBIS list:
  1.) ALWAYS DELETE THE SUBJECT LINE
       WHEN REPLYING TO A MESSAGE

  2.) START THE SUBJECT LINE WITH ONE
       OF THE PREFIXES BELOW.

  3.) SUMMARIZE YOUR MESSAGE IN THE
       SUBJECT LINE (after the prefix)

  4.) ALWAYS INITIATE A NEW DISCUSSION
       WITH A QUESTION (Q:, below) AND
       ENTER YOUR PROPOSAL (alternative) AS
       A REPLY TO IT.

  5.) LIMIT EACH MESSAGE TO ONE (1) POINT.

Message Prefixes
------------------
Here is the standard hierarchy of IBIS-style tags:
   Q: Question
        A: Alternative
             P: Pro
             C: Con

All conversations should start with a question. An alternative (proposed
answer) is always posted in response to a question. Reasons for (pro's)
and reasons against (con's) are entered as responses to the alternative
(one point per response).

In addition to the standard tags, the following additional tags are used
(as suggested by the MapQuest system described in the referenced article
on IBIS):

   CH: Challenges
           Typically used to call a pro or con into question,
           but can be attached to other nodes, as well.
    SP: Specializes
           Puts forth a special case of a particular entry.
    XP: Expands
            Adds more information on the subject.
      N: Note
            A short note.
      E: Endorsement
            Used to "vote" on a proposal. Typically followed
             by your full name, so the roster of those in favor
             can be seen at a glance.
      D: Decision
             Typically occurs under a Q: node, at the end of
             series of A: nodes. Records the alternative that
             was selected, possibly with a summary of the reasons.

IBIS in Email: Additional Usage Information
--------------------------------------------
If you are new to the IBIS method, here is some additional information
you may find useful.

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 can be replicated in email.

First, we need a convention for identifying messages. For a start, we'll
use:
    Q: Question
          A: Alternative
                 P: Pro
                 C: Con

[Note that "A" masquerades as an "answer" when in reality it is an
"alternative" (see "The Answer Reflex" in Jeff Conklin's document at
http://www.gdss.com/IBIS.htm).]

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 prematurely.

[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 a message system that lets a single message be referenced in
multiple threads.]

Here is an example of a thread from an IBIS-style design discussion:
   Q: How will we edit the server-side 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. 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.

Note #1
--------
To use the system effectively, you need to initiate messages with Q:
headings, and change the subject line every time you reply, using the
appropriate tags.
[Future: It would be great if the system could ensure that the
discussion was
"well-formed". For example, by keeping it in XML.]

Note #2
---------
This system will generate MANY more messages than would take place in a
normal mail list. They'll be nicely organized under threads, but there
will be many of them. Making multiple mailing lists is typically a good
idea.

[Future: Ideally, the mailing list would be in a hierarchy that lets you
say "I'm not interested in any detail below this item's sublist, just
let me track the high level
view. Then you could monitor a Q: entry, the A: entries under it, and
the final D: entry that lists the resolution, but ignore the P: and C:
entries and all the detail under it. Of course, you'd also have to be
able to get the detail from the archive if you wanted it. That's all a
bit down the pike, though.]

--------------------------- 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