RE: [unrev-II] Robert's Rules, Decision Models, Education and DKRs, IBIS

From: Gil Regev (gil.regev@epfl.ch)
Date: Wed Feb 23 2000 - 23:10:24 PST


Eric,

You might want to look at QOC which is a Design Rational (DR) Language kind
of comparable to IBIS.
here's a extract from the article at
http://www.xrce.xerox.com/publis/cam-trs/html/epc-1993-106.htm
The gIBIS notation (Conklin and Burgess Yakemovic, 1991) is similar
superficially; the main
difference lies in the latter’s emphasis on capturing the design process for
a particular design
explicitly, as opposed to revising the DR to bring out the dimensions
defining the space in
which the design sits. Reusability is therefore another critical difference
in concerns.

  -----Original Message-----
  From: Eric Armstrong [mailto:eric.armstrong@eng.sun.com]
  Sent: Thursday, February 17, 2000 11:49 PM
  To: unrev-II@onelist.com
  Subject: [unrev-II] Robert's Rules, Decision Models, Education and DKRs,
IBIS

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

  This post combines a report of Jon's highly intriguing
  proposal with a some additional questions and ideas.
  [Another long one, folks. Blame Jon Bosak for lighting
  the fuse...]
  ------------------------------------

  We just finished the 7th session in the bootstrap
  colloquium, which contained Jon Bosak's proposal
  that we automate Robert's Rules of Orders (first
  speaker in the 2nd half).

  To be of real value, Jon noted that it requires a
  DKR -- otherwise there is no way to record the
  arguments, decisions, and documents that result from
  the proceedings. So it may be that his proposal is
  a "2nd order" effort, built on top of an initial
  DKR. But the idea has enough interesting angles that
  might make sense to attempt to co-evolve the systems.

  He gave two references:
    * Proposal
      http://metalab.unc.edu/bosak/pa/pa.htm
    * Preliminary Plan of Action
      http://metalab.unc.edu/bosak/pa/pa-act.htm

  Everybody Does It
  -----------------
  As one interesting angle: Jon noted the large number
  of organizations that that already use some form
  of Robert's Rules for their decision-making process:
  governments, standards bodies, clubs, board meetings,
  shareholder meetings, and on and on. Given the
  near-ubiquity of the process, an automated system
  that included a DKR would certainly "get the camel's
  nose under the tent", as Marcello pointed out
  afterwards.

  Who Can Do It If We Automate It?
  --------------------------------
  Jon's proposal was what he called a "Parliamentary
  Assistant" that shows you all of your options at
  any point in the process, and explains them to you.
  The underlying server keeps track of the parliament's
  state -- are we voting on a motion?, carrying on a
  debate?, etc. [Quibble: I would think of the help
  system as the "Parliamentary Assistant" and the
  underlying server-operations as the "Parliamentary
  Floor".]

  Automating the process in that way then allows
  people to take part across time and space. People
  in physically remote locations can take part in the
  process without having to be physically present.

  The debate on an issue could also take place over
  an extended period of time, with all of the arguments
  recorded. The vote on the issue could then take place
  over a 48-hour period, giving people time to review
  the discussions. (Hence the need for a DKR.) That
  way, we don't all have to be free at the same time to
  participate in the process.

  In response to the question, "won't that preclude
  people who don't have access to the technology",
  Jon pointed out that the technology grows ever
  cheaper and more accessible. At the same time, the
  cost of transportation, the time it requires, and
  schedule conflicts all conspire to make it more and
  more difficult to attend meetings. At some point,
  he notes, the two trends cross. On the other side
  of that intersection, it is more limiting to force
  people to attend a given location at a given time
  than it is to hold such meetings online.

  [Then, too, given such a system our legislators could
  "work from home", which might have the highly beneficial
  impact of keeping them in touch with their constituency,
  rather than becoming part of isolated "power elite"
  in Washington.]

  People We *Know* Do It
  ----------------------
  One of the organizations that uses that method, Jon
  pointed out, is OASIS -- the Organization for the
  Advancement of Structured Information Standards.
  That's the body that started out doing document-
  definition standards using SGML, and which now
  plays a major role in defining and archiving XML
  "vocabulary" standards -- the definition of XML
  structures you can use for specific purposes.
  (Examples of vocabularies include MathML -- the
  XML standard for encoding math equations, a
  standard for specifying vector graphics in XML,
  or one for business-to-business (B2B) ordering
  of office supplies.

  What makes OASIS especially pertinent to us is that
  the most significant result of our efforts might
  not be a product at all, but rather an *XML-standard*
  for a knowledge repository.

  As Doug has pointed out, we won't get very far without
  standardized knowledge containers and mechanisms for
  using them. Otherwise, our systems can't interact with
  each other! Since XML is the odds-on candidate for
  archiving, accessing, and transmitting information
  to each other in an Open HyperDocument System or DKR,
  it stands to reason that a standard XML-based
  vocabulary is precisely what we need.

  Since OASIS uses the Robert's Rules procedures,
  augmenting their process means improving the process
  that defines the very standards we need! It's a
  deliciously recursive process that "bootstraps" quite
  nicely, thank you.

  The whole process may look something like this:
    * We define a working draft of a vocabulary
    * We build a prototype system to work with it
    * Based on the experience we gain from the
      prototype, we revise the vocabulary
    * We put the vocabulary into the hands of OASIS
      to move towards making it a standard.
    * We revise the prototype to use the new
      structures and "do a Mozilla" -- releasing to
      the world at large as free DKR browser/authoring
      tool.
    * The existence of the standard and a usable
      reference implementation leads to large scale
      emulation -- clients and servers are built, and
      the compete for user's favor -- all of which
      "educates the market", which creates the market,
      in reality.

  Would It Help?
  --------------
  Although not all of the chair's duties go away, Jon
  mentioned that such a system would eliminate the
  need for some the more onerous (monotonously
  incessant) activities.

  As the meeting goes on, the system he envisions would
  give you a form at each stage that presents you with
  *all* the available options, and *only* the available
  options. As a result, there would never be a "point
  of order" because you would never be presented with
  an invalid option. [Actually, due to latency, you might
  might be looking at a screen that has not yet been
  updated in response to someone else's move, so you
  might attempt an invalid action. But the system would
  reject it -- and also update your screen.]

  Another wonderful result (at least for the chair) is
  that there would be no more "yielding the floor" or
  things like that, because there is no floor to yield.
  (On the other hand, might you wind up with multiple
  things going on simultaneously, and would that be
  better or worse than the more "serialized" form that
  occurs in a meeting, where one thing happens at a time?)

  Other alternatives?
  -------------------
  During the questions at the end of the 2nd part of the
  session, one ex-lawyer in the session (sorry, I didn't
  catch your name) pointed out that while Parliamentary
  Procedure was one form of decision-making, there were
  others, including the Judicial model (adjudicative)
  where a body of judicial knowledge is built up over
  time, rather than going for a "decision" all at once.
  ["Body of judicial knowledge" -- does that cry out for
  a DKR or what?]

  At the same time, Dave Crocker mentioned that while
  Robert's Rules would work in many societies, there are
  many cultures in which it would be ineffective. He
  wanted us to be alert for cultural bias in our
  implementation, but the combination of his question
  and the lawyerly query put IBIS right on top of my
  mind.

  Switching into IBIS mode (God, I love that paper), I
  realized that the question Jon was answering was the
  one he alluded to at the beginning of his presentation,
  namely "How do we go about making a decision in tough
  cases, where people are going to disagree even if they
  have all the facts at their disposal?" (He gave
  abortion as a well-known example.)

  Robert's Rules has the advantage of 400 years'
  experience behind it, with good minds wrestling down
  the "corner cases" all the way. It is also a codified,
  documented procedure, which makes automation a
  straightforward task (unlike an ad hoc procedure). But
  it is not necessarily the *only* way. (A point with
  which Jon agrees.)

  To "open the design space" then, here is a fundamental
  question:
    "What decision-making models exist that we might be
     able to implement with technology?"

  The alternative suggested by Jon is Parliamentary Procedure.
  Another suggested alternative was judicial procedures.
  Are there others? What are they? Why do you think they
  would be good?

  IBIS?
  -----
  It is tempting to consider IBIS as an alternative
  decision-making model. There are two cases in which
  it is:
  1) In an autocratic situation, where everyone has
      their say and endorses their favorite proposal,
      and then the "supreme ruler" makes a decision.

      In this case, an automated model has still played
      a major role. It has recorded the alternatives
      and the arguments for them, so they can be
      re-examined later. It will have "kept the
      alternatives alive" so they are not forgotten.
      That means that every alternative which was raised
      will have it's moment of time, and be inspected
      by the group, which is a good thing.

      But that system only works where there is a "head
      dog" to make the decision. It is still possible
      to reach agreement in a meeting of equals, though,
      in one case:

  2) When a decision is reached by "acclamation".
      Let's say that we have two alternatives. Three
      people endorse #1, and 2 people endorse #2.
      After reflection, perhaps one person changes
      their endorsement to #1. Then the last person
      decides to "go along with the group", and
      endorses #1, as well. The voting is now unanimous,
      and a decision has been reached.

      [Note: The implication for an IBIS implementation
       is that it must be possible to "change" an
       endorsement. The original endorsement should
       probably remain on record, but link to the new
       one. Making the change should either require an
       explicit "change endorsement" action or, if a
       accomplished by the simple act of endorsing a
       different alternative, the system should verify
       that you want to change your endorsement. (You
       may have forgotten that you endorsed a different
       proposal earlier and may need to review your
       original reasons. When the system looks for
       endorsements, it should ignore any with a non-null
       link.]

  For the kind of system-design work that goes in an
  open-source development environment, the "acclamation
  model" might well be sufficient. However, it only works
  so long as an impasse never occurs.

  Handling an Impasse
  -------------------
  But what happens when you reach an impasse?
  Ideally, all the questions would result in a decision by
  acclamation. But when they don't one possible solution is
  to move the decision process to a Parliamentary Session.

  Another possible solution is one that Java-inventor
  James Gosling made into a mantra: Do Nothing!! James made
  the astute point that when bright minds cannot agree on
  the right thing to do, maybe the problem is too murky to
  make a decision! Rather than making the *wrong* choice,
  and saddling people with an unattractive design, it was
  better to leave that feature out of the design until the
  waters clarified (if ever).

  An interesting example of that theory might be the
  developing W3C standard for XML schemas. Apparently many
  people feel that it has become rather huge and complex
  (much like SGML). It would be interesting to investigate
  the organizational and social reasons for that result,
  but it is reasonable to speculate that it resulted from
  the politics of "satisfying everyone" -- of not disagreeing
  with anyone else's proposal so that your own would be
  accepted.

  In contrast, one of the original members of that standards
  effort (from Japan) apparently left and produced a very
  small, compact schema standard named RELAX. Like XML, that
  one appears to be a drastically reduced, easier to understand
  standard that still manages to achieve the most important
  goals of it's larger cousin. (The jury is still out on that,
  but it may well be the case. Bill Smith pointed out that
  when they presented XML, they heard complaints from individual
  after individual over a 3 hour period that "they left out
  feature X" -- but no two people ever named the same feature!
  It seemed that all the features they left out were really
  idiosyncratic ones -- not core features that everyone
  needed. He said he knew then that they were on the right track!

  That experience, along with the general "design by committee"
  scenario, seems to imply that IBIS-style procedures might well
  be sufficient for automating open source design efforts. In
  those cases where consensus cannot be reached, perhaps no
  decision at all is the wisest course!

  It must be pointed out, though, that "no decision" is hardly
  effective in all cases. In governmental regulations, for
  example, either you make a change or you live with the status
  quo. Doing nothing is effectively a "decision". For those
  cases, if you are going on the basis of majority rule, you
  need (or at least can use) parliamentary procedures.

  To augment many of the decision-making processes that are
  currently going on in the world, then, it may make sense to
  automate parliamentary processes. Then, too, as Jon pointed
  out after the session, you can always adjust the system to
  set the standard you want. You can define a "majority" as
  50%, 75%, all-but-one, X% in favor and no more than Y%
  against.

  [Summary: It may be possible to coevolve a parliamentary
  augmenter with a DKR. If not, it would seem that the
  a DKR / OHS / IBIS system for Open Source Development
  would have higher precedence.]

  An Individual's DKR
  -------------------
  It may be that the "judicial"-style DKR is appropriate
  for an individual engaged in doing a design. That DKR
  might contain all the information you digested as a
  student, and all the design experience you acquired since
  then on the job. As you think about how the system should
  be implemented, you may well consult your DKR for ideas,
  alternatives, and suggestions.

  You might then publish the results of that investigation
  in the "project DKR" for the system you are building. Your
  stored knowledge, in addition to thoughts you generated,
  would then be part of the project's knowledge repository.

  Others interacting with the repository might save that
  information as part of their personal DKR. Some parts they
  might choose to ignore, as outside their area of expertise,
  superflouous, or redundant with previously stored material.
  But the useful parts would become part of the compact DKR
  they carry forward in life.

  In this system, the goal of education might well to add
  material to a student's DKR -- material they understand and
  can access when needed. As ideas and knowledge migrate from
  repository to repository, human knowledge spreads. That
  may be the fundamental idea of "idea as virus" in books
  like (or based on) Richard Dawkins' "The Selfish Gene".

  IBIS Front End?
  ---------------
  When Jon mentioned the "forms" that would guide you
  through a Parliamentary Process, it brought to mind a
  related issue with IBIS. I'm not a big fan of forms,
  but perhaps a system that "limits your options" for a
  response according to context would help in an IBIS-style
  discussion, as well.

  For example, in IBIS you never make a proposal without
  first asking a question -- that identifies the problem
  you are trying to solve and keeps the design space open
  by providing a place to hang other alternatives.

  An implementation that did not let you identify a message
  as being of type "alternative" unless you were responding
  to a message of type "question" would ensure a
  "well-formed" IBIS discussion. [It still might not be totally
  "Valid" since as Jeff Conklin points out it is possible
  to ask overly-limited question like "Is X a good idea?" or
  "Should we do X or Y?" Still, forcing the discussion to be
  well-formed would be a step in the right direction. Later,
  it might be possible to look for occurrences of a alternatives
  in the question, which would lead the system to question the
  validity of the question.]

  On the other hand, after the session Marcello related his
  experience with a system called TheCoordinator that Terry
  Winograd was involved in creating 10 years ago or so
  (1989?). Apparently that was an email-based system that made
  you tag your messages as "hypothesis" or "argument" and such.
  It turned out that some people loved it, but others hated
  it. Marcello was in the later camp. Apparently it prevented
  free-wheeling brainstorming, forcing you to label your
  messages prematurely, before you even knew what they were.

  That experience should be taken into account, along with
  the paper that described the difficulties that people had
  in dealing with IBIS. It may be that the right way to
  approach IBIS is as a hierarchy that build *on top* of
  a free-wheeling email discussion, by creating tagged nodes
  that point to elements from that discussion. Keeping the
  labels separate from the messages might provide the best
  of both worlds, and make it possible to make new versions
  of the IBIS summary without affecting the underlying
  discussion at all.

----------------------------------------------------------------------------

--

Please click above to support our sponsor

---------------------------------------------------------------------------- -- 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:52 PDT