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

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Thu Feb 17 2000 - 23:48:31 PST

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
  * Preliminary Plan of Action

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

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

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

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

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

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

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%

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

--------------------------- ONElist Sponsor ----------------------------

Get what you deserve with NextCard Visa. ZERO. Rates as low as 0
percent Intro or 9.9 percent Fixed APR, online balance transfers,
Rewards Points, no hidden fees, and much more! Get NextCard today and
get the credit you deserve. Apply now. Get your NextCard Visa at
<a href=" http://clickme.onelist.com/ad/NextcardCreative3CI ">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:

This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:49 PDT