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

From: Henry van Eyken (vaneyken@sympatico.ca)
Date: Fri Feb 18 2000 - 03:49:06 PST


From: Henry van Eyken <vaneyken@sympatico.ca>

Eric:

While still in the "catching-up" phase and therefore still well away from seeing
Sesion 7 with Jon Borsak's presentation, I did read (hastely) your post on this
topic.

A fine feat of clarity, wow! Your lucid writing permitted me to drop into the
topic and have a sense of what's going on. I also sensed a potential for
improving and widening the democratic process. Definitely want to later attend
to this part of the discussions.

I feel stimulated and prize myself lucky to be in the company of good people!
Just hope I can sufficiently thin the molasses that lubricates my mental gears.

Henry

P.S. Just a very subjective remark. I noticed in your essay a reference to
accomodating "cultural differences." Reminded me of a critique I just read in
The Economist of the latest work by philosopher John Rawls. In a previous work,
"A Theory of Justice," he took a stance on principle. His latest, "The Law of
Peoples," received less than stellar acclaim for a backpeddalling that allows
for democratic countries to accomodate less-than-democratic regimes. (Issue
Feb. 12, p. 88: "The social contract: Less original positions.") It seems that
principle and pragmatism make poor bedfellows.

Henry

Eric Armstrong wrote:

> 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.
>
> --------------------------- 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:
> http://www.onelist.com/community/unrev-II

--
Fleabyte -- http://www.fleabyte.org -- is
an evolving, experimental web-publication
devoted to public computency, which, like
common literacy, is regarded as essential
to an environmentally healthy, democratic
society.

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

Get what you deserve with NextCard Visa. Rates as low as 2.9 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/NextcardCreative1CI ">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:49 PDT