This version:http://metalab.unc.edu/bosak/pa/pa.20000225.htm
Current version:http://metalab.unc.edu/bosak/pa/pa.htm
This paper suggests that a legally valid formal decision-making process can be implemented using systems of web servers in a way that will make participation in formal decision making much easier and thus practical for a much larger number of people than is currently the case.
The purpose of this proposal is not to replace our traditional democratic processes with new ones but rather to make the traditional processes usable online in a way that can extend the benefits of participatory democracy to our existing institutions.
If systems of the kind imagined here are practical, their deployment could have revolutionary implications for social policy. Whether such systems are possible in reality remains an open question pending successful implementation. This paper is intended to serve as a starting point for attempting such an implementation.
Robert's Rules of Order is the default legal process for most corporate, fraternal, professional, and other social groups founded during the last century in the United States. First published in 1876 as a synthesis of existing practices derived from British parliamentary law and continuously revised since then, Robert's specifies the creation and maintenance of what are technically known as deliberative assemblies. It is through the action of deliberative assemblies that most of our public business is legally conducted.
It is generally accepted that our deliberative assemblies must operate in a manner that is formal, fair, and democratic. It is generally agreed that Robert's provides such a process. If we ignore the sometimes musty terminology of traditional parliamentary procedure, it may not be going too far to say that the process described by Robert's is basically what anyone would get if he or she thought through the fair and orderly operation of majority rule.
There is a lot to be said for the traditional approach to group procedure. After centuries of use it has been thoroughly debugged and tested under every conceivable set of circumstances; this demands respect from anyone who has tried to construct group processes. Robert's is built into most of our parent organizations (commercial and otherwise); its documentation is very widely available; it knows how to bootstrap itself; and it can continue to function even when resolving questions about which there are deeply opposed points of view.
Furthermore, Robert's is a process designed for the generation of documents. It can be used for the collaborative design of very complex documents such as legislative acts and, in theory, for the collaborative design of technical specifications. But many of us are reluctant to put the machinery of Robert's into action. This proposal is based on the observation that the antipathy toward Robert's is due, in large part, to the burden of maintaining the procedural overhead of the process.
The traditional system described by Robert's is one that most people can understand with some hard study and that nearly everyone can use if guided by a person designated by the group to learn the process. This person is typically called the parliamentarian. If given the benefit of a parliamentarian and a little training among the members of a group, Robert's works fairly well even under very heavy use -- but only face-to-face. It is almost unusable by email.
The asynchronicity of email imposes a latency on the process. Even in a very focused community, it is difficult to reduce the latency to less than about 48 hours if the group is to include people who travel. This time lag is acceptable for formal votes, but it practically destroys the point-counterpoint quality of the Robert's amendment process -- and if the document under construction is a law or a technical specification, it is in the amendment process that all the design takes place. Add the latency of two more days for the ordinary hard-working human chair to respond to inputs and we have, in effect, a four-day turnaround for every cycle. This is just too slow, even if the chair never fails to meet a 48-hour turnaround commitment.
This proposal argues that we can take the chair as presently conceived out of the loop in a Robert's process carried out over the Internet. If the present function of the chair can be replaced by simple majority rule in online environments, the cycle becomes limited only by notification requirements, and it can be almost instantaneous for parliamentary procedures that do not require votes.
A process running under strict compliance with Robert's is a state machine. Its state is the information that would, at any moment, have to be saved overnight if a deliberative assembly adjourned until the next day. This state includes the procedural state (most obviously, the stack of pending motions; see Robert's Rules of Order, Ninth Edition, pp. 113-115 for an example) and the current state of the associated document database.
The machine defined by a Robert's process has a command set, which is the set of all formal inputs (motions and statements entered in debate) that can be made at a particular moment by the members. At any stage, the command that gets executed next is the first legal command received. The legality of a given command at any stage depends on the current state, the category of the command, and, to some extent, the past history of the member making the motion (for example, participants cannot second their own motions, so the history of having made or not made the motion adheres to every participant in considering the next acceptable command).
A legal process running under Robert's constitutes a parliamentary automaton. This paper proposes that we implement such machines in software. We suggest the name "parliamentary assistant" (PA) to emphasize that the machine is driven by humans.
The attempt to remove the chair (as ordinarily conceived) from the critical path of the process should not be understood as an attempt to function entirely without a person responsible for certain administrative functions. The interesting question is just which of the traditional functions of the chair can be assumed by a machine if one is willing, as Robert's is, to let a simple majority make all the important decisions. It turns out to be productive to start by asking which functions of the chair are no longer necessary in an online environment.
If decisions are understood to be the job of the group rather than the chair, then most of what the chair does in traditional contexts is to resolve priority conflicts, particularly priority conflicts with regard to being recognized and heard, either to make motions or to engage in orderly debate. All priority conflicts are due to multiple persons attempting to do something at the same time. In an online environment, however, such conflicts between human beings are virtually impossible. Messages arrive in a certain order determined ultimately by the structure of the network; it is not possible in this environment for one person to interrupt another, and as long as motions are received in a determinable order, the state of the process can automatically be determined. The removal of priority conflicts eliminates a large part of the actual work of the chair. Indeed, it is this quality that makes collaborative work in unmoderated Internet forums possible at all.
Another load imposed on the chair by the traditional process is maintaining the order of the process itself. This load can be removed by a properly designed software implementation. A complete implementation of the process can decide at any point whether the next item in the queue of inputs to be processed is in order, execute it if so, and bounce it back to the sender if not. It should not be possible in a properly realized PA for an error in procedure to occur, and if it does, it should be considered a bug, not a question that is to be solved by human intervention in the general case. Thus, everything in the traditional process relating to points of order and their resolution can be removed from the online version.
An important if relatively little-exercised function of the chair is regulating the level of debate. Ways of formally taking offence with another participant and resolving disputes over insulting language constitute an essential part of traditional parliamentary procedure. But the purpose of such procedure is not the prevention of bloodshed (though that is a helpful side effect) but rather the prevention of disturbances that would interfere with the process. In the online environment, however, disturbances that would prevent the actual functioning of the machine are almost impossible; as we have discovered in other contexts, the online equivalent of shouting and character assassination, while deeply annoying, can simply be ignored without injury to the process itself.
Robert's gives the chair the function of determining the relevance of an input to the question at hand. For example, when an amendment to a main motion is pending, it is the duty of the chair to rule out of order any debate on the main motion itself if it is not relevant to the amendment. But here, too, the medium makes this function largely unnecessary. Within very broad limits, we do not care very much about simple irrelevancy any more, because irrelevancy alone cannot stop the online process in the way that it can stop the face-to-face process.
It should be noted in connection with the last two points that there ought still to be a method of last resort whereby a deliberative assembly can remove a member who is completely out of control. But it is not possible in the general case for an unruly member to actually prevent the execution of a formal process that would remove him from the list, and therefore a direct remedy for the worst case is always available.
It may be objected that in addition to discharging the formal obligations of the position, the chair of an assembly provides leadership as well -- setting forth a vision, ordering an agenda, resolving personal conflicts, negotiating compromises, steering around ideological minefields, and so on. This is undeniably true, but leadership as something separate from the procedural role is a quality that may be exhibited by any number of participants, and it does not have to be exercised through the role given the chair; it can be manifested during the course of debate on a question or even through private conversations among the participants. If the potential for leadership exists in a group, there are a number of avenues for its expression; it should not be necessary to appoint a traditional chair just to provide leadership.
This is not to say that all functions of the chair can be replaced by a machine. For example, while the duty of the chair in the traditional process to state the question can easily be replaced by the machine in an online environment, it is also the duty of the chair to decide whether a motion makes sense and whether an amendment on a question relates to the question.
With regard to dilatory motions, it is possible that we will find upon further examination that we can live with them just as we have learned to deal with abusive debate; standing rules limiting the number of motions that can be offered by any one participant in a given period of time might take care of this. And with regard to irrelevant amendments, a strict enforcement of the mechanism for making an amendment (specifying the words to be stricken out and the words to replace them) could keep this formally on track under most circumstances. But there is likely to be a residuum of judgments about relevance that cannot be made by a machine and are not practical to make by majority rule.
The form of motions presents a similar difficulty. Motions are always supposed to be stated in the positive: "I move that we do P" rather than "I move that we do not do P." Imposing this kind of lexical constraint is very easy for a human and very hard for a machine.
Setting agendas is also a problematic area generally delegated to the chair. A mechanism for determining "the orders of the day" will be a difficult piece of design.
It will probably always be necessary to be able to identify a person responsible for the process. The key is to make human intervention a rare occurrence and to make the duties of the chair resemble more closely the duties of the person ultimately responsible for running a mail server and less closely the duties of an authority figure standing in the critical path.
While certain features of a parliamentary assistant might seem to require artificial intelligence, in fact the basic challenge here is the reverse of the usual, much harder AI problem. A typical example of an AI application is a point-of-sale terminal that can understand arbitrary human input. The difficulty in such an application is that the machine has to understand whatever the human says and cannot simply reject it. The PA, on the other hand, is a kind of AI application in which we want the machine to reject what it cannot understand. This difference is critical to the prospect of successfully implementing a PA.
While it is possible to imagine a PA implemented simply as an extension to a mail server, the machine would be much more capable and user-friendly if implemented as a web server that uses email "push" capabilities to keep participants abreast of major changes in state. Implementation as a web server would have several important advantages.
The choices legally open to a particular voting member at any point in the process could be represented by means of a form rendered by a web browser, with the legally available options at that moment indicated through menus, radio buttons, etc.
This feature alone would completely change the experience of working with a parliamentary process. Participants would never be in doubt about what they are legally permitted to do at any point and would never have to worry about the proper procedural language to use. Ordinary online help could be used to explain each option.
The server could provide the front end to a document database capable of showing the complete history of every document created by the process and the complete history of the process itself, including all debate.
This implies the existence of a reasonably complete document database system.
Since a server-based PA is a running machine, it should be possible to apply machine optimizations to the process.
For example, consider the motion to end debate on an issue (known technically as Previous Question). In the traditional process, debate on a question is suspended while the Previous Question is called and a vote is taken. If this were realized in software simply by copying the traditional process, a call for the Previous Question would add a complete voting cycle every time it was made. But in the online version, the common hardware techniques of pre-fetching and parallel processing could be applied to optimize this.
Since Previous Question is not debatable or amendable, a motion for the Previous Question could be made while a question was pending without interrupting debate on that question, and it could be allowed to gather votes in the background subject to a timeout parameter while debate continued. If the necessary 2/3 vote were obtained before timeout, Previous Question would succeed and the main question would go for a vote immediately. Furthermore, since it is reasonable to assume that every person voting for the Previous Question is ready to vote on the main motion, it should be possible for the PA to fetch the vote on the main question at the same time that it receives an affirmative vote to close debate, using the same interactive form. This anticipatory vote on the main question would be held in confidence and used only if the vote on Previous Question carried, in which case it would be applied immediately and automatically when the main question was put to a vote. Thus, it should be possible to eliminate both the time usually taken to consider Previous Question and also the time it would usually take to gather votes on the main question from all of those who are ready to invoke Previous Question.
It is possible that the same principle could be more generally applied to all non-debatable motions. This specific example needs a great deal more thought to consider all the details, but it demonstrates that careful engineering should be able to streamline the process without affecting it from a procedural point of view.
Note that there is no suggestion here that substantive issues be considered in parallel; this would not only be confusing to the participants but would probably break legal equivalence with the existing traditional process. The observation here is that there is already a distinction in Robert's between main motions, subsidiary motions, incidental motions, and privileged motions that suggests the definition of a class of "metamotions" that could be considered in parallel with the actual business of the assembly.
As a special case of optimization, it should be possible to separate the administrative layer of the process as a parallel thread.
For example, a proceeding to discipline or remove a participant should be able to take place in parallel with the substantive business of a society and thus not be allowed to impede the operation of the PA. While this, too, needs a great deal more thought, it would seem possible to handle most such motions by allowing them freely to be made in the administrative track subject to a timeout. With this separation between administrative and substantive issues, an unreasonable minority could not use administrative motions and appeals to hinder the process, because such motions, if lacking a basis, would fail to gather a majority during the allotted time and would harmlessly disappear; in other words, under most circumstances, the majority could simply ignore activity in the administrative track, because without the interest of the majority, nothing could happen there. But a majority genuinely concerned with an administrative issue could use this mechanism to bring the issue to swift resolution.
If we consider the set of motions to constitute the command set of a machine, then we can also consider possible extensions to this command set.
For example, the command set could be extended to include a "Motion to Connect" that would, if approved by resolution of two or more PAs, create a specialized child PA to instantiate a joint subcommittee empowered to perform coordinative functions among them. This would enable the spontaneous generation of coordinative organizational networks.
Since extensions of this kind go beyond the mechanism provided by the traditional process, they would have to be explicitly enabled by changes to the bylaws of organizations wishing to adopt them.
The concept of recursion is deeply embedded in the traditional process. Amendment is a recursive process in which a main motion calls its own machinery to create a subprocess with the same formal mechanism; indeed, the question is said to "recur" when an amendment is resolved and the process returns to the main question. At a higher level, to form a committee is to call into existence a child PA. A well-designed PA can use these recursive features to minimize the number of different modules needing implementation.
The basic "clock cycle" of a PA is the period allowed for voting. Among other machine parameters, the clock cycle should be chosen by the participants as part of what, in the traditional process, would be called "standing orders." In an organization whose members included frequent travelers, for example, the clock cycle might be set at 48 hours to allow members in transit time to catch up with email notification of a vote in progress.
The user interface to a web-based PA could be as easy to use as the interface to an online retail system. Here are some of the more obvious possible features of such an interface.
A window into the current document hierarchy: every document submitted during a formally recognized phase of the proceedings, preferably (but not necessarily) with a mechanism that shows version history.
A summary of the current procedural state of the machine that allows examination of any item currently on the stack. (If optimization of the kind suggested above is used, this could be divided into a substantive track and an administrative track.)
An interactive form showing the actions allowed to be taken by the particular member at this point. (Again possibly divided into parallel substantive and administrative tracks.)
The most common user actions in this environment would be (a) making a motion, usually with text attached, and (b) submitting text messages during open debate on a pending question. Motions and simple text entry can easily be accommodated through HTML forms, but for longer entries a more powerful input tool would be needed. A really good PA implementation would allow users to preview the effect of submitting a particular action form by showing what the state of the machine would be if that form were submitted at that instant.
As noted above, email should be used to keep members informed of motions made, votes pending, and other significant events in the state of the machine. A typical message should show who has just done what to the machine (including any associated text) and should summarize the state of the machine immediately following the action. This would allow a traveling participant to track activity by following in email and touching base with the server only when a vote is called.
A web-based PA of the kind proposed here would have a number of interesting characteristics.
Within the basic clock cycle chosen by the members, it would be completely asynchronous. Thus, the geographical location of participants would not matter.
On the other hand, it would be instantly responsive to any legal request from the user, including procedural requests that did not require a vote (such as giving notification) and non-procedural requests to examine information or explore the effects of various hypothetical actions.
It would proceed fairly steadily as long as people were still participating; that is, it would not come to a stop just because participants were disagreeing. As long as a majority of voting members are willing to cast supporting votes, it takes only two active members to drive a PA defined by Robert's.
The table of 84 kinds of motions in Robert's looks complicated if viewed as a set of meeting rules but not if viewed as a set of machine commands. Eighty-four commands is not a large instruction set, and in the proposed implementation each one would be mediated by an interface that would tell the user which commands were legal at any given point and what their effect would be. Ordinarily intelligent people could learn to participate in this process, especially if they were willing to let more experienced members work the controls while they were learning their way around. The use of Robert's to run untold numbers of church groups, fraternal organizations, and labor unions over the last century proves that the process itself is within the capabilities of every citizen if access is provided.
Given a good interactive UI, a web-based PA could acquire social dynamics not unlike that of a multi-user computer game. Indeed, if the reponse cycle can be made short enough, a PA might begin to exhibit the emergent property of a human/computer system that Douglas Engelbart has called "collective IQ."
A good UI would not only provide a much more supportive environment than the traditional unautomated process, it would also provide a neutral, nonjudgemental mechanism for keeping debate within certain boundaries. For example, consider this rule from Robert's for the conduct of debates in full assembly:
[E]ach member has the right to speak twice on the same question on the same day, but cannot make a second speech on the same question so long as any member who has not spoken on that question desires the floor.
The notion of gaining the floor no longer applies in an online environment, but the electronic equivalent of this rule would be easy to implement and could have highly beneficial effects on the quality of debate. Not only would a limitation on the number of messages per day tend to improve the quality of messages; it would materially lighten the load of any participant seriously attempting to read all of the messages posted in a debate.
It would also be relatively easy to accommodate lurkers in this environment. At the option of the voting members, or of the authority by which the PA is created (a motion to create a committee being a motion to create a PA), the extent to which non-voting members are allowed to participate could be finely tuned through the UI. For example, the server could be set up to allow anyone to examine the document base, check out the state of the procedure, and enter text messages (up to the daily limit) related to the pending question, but allow no one but voting members to make motions. Nonmembers who abused the right to comment could be refused access to the server by a vote of the members, just as in the traditional process.
In an online PA, it is likely that much personal interaction would take place (as it always has) "off the record" in group and private email, in chat channels, and in group and private phone calls. Depending on the style of the group, it is even possible for the great bulk of discussion to take place off the record and to use the PA only for the formal registration of decisions that have been substantially decided informally, just as is often done in the traditional process. It is equally possible, however, for the group to require all conversations to take place on the record, thus automatically providing an audit trail of the entire deliberative process.
Because older forms of electronic conferencing are typically closed to the public, California's Brown Act prohibits "any use of direct communication, personal intermediaries, or technological devices that is employed by a majority of the members of the legislative body to develop a collective concurrence as to action to be taken on an item by the members of the legislative body" (sec. 54952.2(b) Government Code). It should be possible to construct a PA whose workings are accessible enough to meet the Brown Act's requirement for "open and public" meetings. Indeed, because of its potentially much greater accessibility, it should be possible to provide more actual transparency and accountability in our public commissions, boards, and councils than can be achieved even under the provisions of the Brown Act and similar laws in other states.
Computer-mediated discussion is hardly a new idea, but what is being proposed here is not a discussion machine or an exploration machine; it is a legally binding, formal decision-making machine.
Formal decisions have to be made, and making them well requires a formal process. Using such a process is a thankless but unavoidable task. It is also a well-understood but tedious task. In short, it is just the sort of thing that computers are supposed to be able to take care of for us.
An implementation of a PA as (for instance) a freely available add-on to the apache web server could bring order and fairness to any number of rule-making activities that are attempting to carry out their business over the Internet.
Beyond that, however, the ubiquitous availability of legal decision-making in a form as easy to use as the interface to an online retailer could finally make local democracy a practical reality. A mechanism that allowed internationally distributed communities defined by common interests to run themselves could also allow communities defined by physical boundaries to run themselves. It is not hard to imagine this mechanism being used for the governance of local bodies such as neighborhood associations and condominium boards. The ability of the electronic process to resolve the scheduling conflicts and alleviate the procedural burdens that now prevent most people from participating in local government could have profound implications for the structure of our society.