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

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.

  
  

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:

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

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.

Sincerely,

Eric Armstrong