HL7 Process Issues:Liora Alschuler, September 12, 2000

HL7 Process Issues:Liora Alschuler, September 12, 2000

1. Quorum

Without rules for quorum, it is impossible to know when a Committee is able to act. Our “policies and procedures” seem to be silent on this crucial point, which may mean by default we should follow Robert’s Rules, but these rules do not fit our distributed membership. We need rules for committee membership that establish workable quorum requirements for face to face meetings, conference calls, and both in-cycle and out-of-cycle meetings. (This issue has been addressed by Jon Bosak, see article below which describes the legal liability of organizations such as ours that do not address this issue).

[NOTE, 6/02: Karen and Wes have determined that ANSI sets out no requirement for either a quorum or RROR. However, the ability to conduct meetings and make decisions is predicated on some notion of group definition and I continue to believe that we are open to challenge on this, should someone decide to take issue with our policies and procedures. The rationale is well covered by Bosak below.]

2. Work products

Too often, the first committee-level ballot for a specification functions as the first comment cycle because there is no organization-wide, formal publication and comment process prior to ballot. We need a formal specification development process that includes publication milestones and comment windows. The W3C uses this process to good effect in that when a version of a draft standard is posted for public review, it is a milestone that marks a new level of stability in the spec. The target dates for these draft publications are themselves published so everyone knows where the current draft is in development and when to expect it to be superceded. Some milestones, “last call”, specify time intervals for comments. Without this, comments come in randomly, so editors can complete work on a section, only to receive important input shortly after the fact while reviewers can put great effort into a review, only to see a new version published before they complete it. We need to synchronize and make public (at least to members) pre-ballot review and revision cycles.

[NOTE, 6/02: SDTC intends to issue the next CDA as a formal “Draft for Comment” prior to ballot. This will not lessen the ballot requirements per our by-laws, but we hope it will create a more streamlined and effective interaction with membership who wish to influence the design of the specification.]

3. Agendas

We need formal guidelines for agenda creation and publication. These guidelines will allow co-chairs the perogative of setting the agenda while providing an avenue for input for members. We need guidelines that specify what is expected of someone asking for agenda time and we need guidelines that establish deadlines for submission of agenda items and deadlines for publication of the agenda. In the absense of such procedures, co-chairs are hit with requests for agenda time for important topics during the week without the opportunity to prepare members for the discussion or to create overall priorities.

[NOTE, 6/02: Similar to Steve W’s points. Same applies to conference calls, although procedures should differ.]

4. Work items

In addition to the Mission & Charters, we need formal, published lists of active work items for each group. These will make it possible to evaluate proposals that come to committees and it will make it possible to have some sort of general, organization-wide oversight and coordination.

[NOTE, 6/02: SDTC has done this and posted it from a persistent link on our home page.]

5. Ballot review

We need to review and revise the process for addressing negative and positive ballot comments. While the balloting sequence itself is open and equitable, the process for responding to ballot comments has several weaknesses, chief among them the reliance on the face-to-face meeting time to respond to and resolve ballot comments. The requirements of a f2f meeting are such that it is impossible to have input from the ballot pool during comment resolution. This creates an imbalance weighted toward those who are present to make their case and weighted against those who voted and commented without knowledge of the comments of others. The f2f time should be used to resolve issues that have already been articulated and published. Thus, before the final f2f meeting, comments and proposed responses should be published, the time for the discussion should be fixed and publicized such that the entire ballot pool has an opportunity to be present or to provide input into the process. As it stands today, a small portion of the ballot pool can take an action in response to a ballot comment and the majority of the ballot pool has no opportunity to respond until the next formal ballot.

6. Protocol between co-chairs, officers [added October 31, 2000]

We need to establish a climate of mutual respect based on contributions to HL7 and the responsibility to membership inherent in holding an office of co-chair or Board member.

[NOTE, 6/02: major issue. Many times, cooperation and progress are pocket-vetoed by a co-chair who simply fails to respond. The behavior is not limited to co-chairs, but should not be sanctionned by those who carry the responsibility for representing committees and seeing that issues are addressed in a timely manner. I think this is a symptom of a greater underlying problem, that our flat committee structure no longer meets the needs of the complex and inter-related work products, but improvement in communication between co-chairs, a minimum-acceptable level of communication, would help.]

(the following is taken from an article published on XML.com, my emphasis)

The OASIS Process for Structured Information Standards

By Jon Bosak, Chair, OASIS Process Advisory Committee

OASIS, the Organization for the Advancement of Structured

Information Standards, is a nonprofit corporation founded in 1993

under the name SGML Open. Originally a consortium of small

software vendors and large customers devoted to developing

guidelines for interoperability among SGML products, OASIS changed

its name in 1998 to reflect the inclusion of CGM Open and the

growing popularity of the XML subset of SGML.

In 1999 OASIS began two important projects -- the XML

registry/repository at XML.org and, in cooperation with UN/CEFACT,

the Electronic Business XML (ebXML) initiative. It also changed

its membership rules to include individual members as well as

corporate sponsors. Today OASIS is an organization in transition

whose future direction depends largely on the extent to which

interested individuals decide to participate.

The process by which OASIS develops information standards is also

in transition. The overall structure of OASIS is that of an

ordinary nonprofit corporation with an elected board of

directors. The board is responsible for business and policy

decisions, while the membership itself is responsible for deciding

substantive technical issues such as the approval of

interoperability guidelines. As would be expected in what was

historically an industrial consortium, "membership" for purposes

of electing the board and voting on technical resolutions includes

just the organizational members, with one vote going to each

organization. More will be said about the relationship of

organizational and individual members below.

As a nonprofit corporation, OASIS is bound by law to follow the

procedures set forth in its corporate charter and bylaws. The

OASIS bylaws, like those of most U.S. corporations, specify

Robert's Rules of Order as the procedure to be followed by the

OASIS board of directors and by committees created by the board.

Thus, adherence to Robert's is a requirement imposed by law. This

means, among other things, that members can seek legal relief if

their rights are not respected under the traditional parliamentary

process specified by Robert's.

While potentially complex and sometimes tedious, the Robert's

process has a number of advantages for an organization devoted to

the development of industrial standards. As the synthesis of some

four centuries of evolution in parliamentary procedure, it is the

epitome of majority rule in practice. It has been thoroughly

debugged and tested under just about every conceivable set of

circumstances; it is built into most of our governmental and

corporate institutions; its documentation is very widely available

(see below for further information); and perhaps most importantly,

it can continue to function even when resolving questions about

which there are deeply opposed points of view. It is not

surprising, therefore, that Robert's is the process used by ANSI,

IEEE, and a number of other highly regarded standards

organizations.

Robert's also has some disadvantages, but they are not the kind

that some people imagine. The widespread belief that Robert's

necessarily imposes an inherently slow and difficult procedure on

technical development is simply not true. Robert's rules for

committee work are much more relaxed than the rules for full

deliberative assemblies that most Americans learn in civics

classes, and in the hands of a knowledgeable chair, a committee

running under Robert's can move just as quickly as a less

structured group. It's true that the process slows down

dramatically when confronted with real disagreements among the

participants, but so does any process that recognizes disagreement

and attempts to deal with it fairly. The difference between the

traditional process and more informal ones is that the traditional

process always produces a decision no matter what the level of

disagreement, while less structured processes dodge the problem by

appealing to a higher authority or, in the worst cases, simply

ceasing to function.

The real problem with using the traditional process in standards

work has to do with its quorum requirements. A quorum is the

minimum number of members that have to be present before a

committee can conduct business.

Under Robert's, committees are made up of particular individuals

appointed by name. A committee can invite observers to

participate, but it cannot add voting members, or remove voting

members, or change its charter, or do anything else that might run

contrary to the intention of the body that created it. So the

composition of an existing committee can be changed only by formal

resolution of the body that appointed the committee. There are

very good reasons for this system; it ensures that committees

include only those people judged qualified to carry out the work,

and it prevents committees from being "stacked" by the ad hoc

participation of groups with views on a particular question. But

frequent personnel changes in modern companies make the staffing

of technical committees by direct appointment unwieldy in

practice.

One solution to this problem would be to appoint to the committee

everyone who expressed interest in it and trust that enough of

them would remain involved over the life of the committee to

carry out its work. But here the quorum requirement intervenes.

Under the default process specified by Robert's, a committee

meeting has to be attended by a majority of all the appointed

members in order to conduct business.

The quorum requirement is important because it prevents a small

subset of members from acting in the name of the committee and

thus ensures that decisions actually represent the thinking of the

majority of the group. But it is a sad fact of standards work

that few of the people who express initial interest in the work of

a committee will ever actually attend any given meeting. This

problem is exacerbated by the impossibility of substituting one

person for another without the approval of the body that created

the committee. The result is that a Robert's committee must

consist of a relatively small number of specifically named people

who are genuinely committed to attending every meeting; otherwise

it will fail to achieve a quorum and will be unable to conduct

business legally.

To address these and other issues related to the creation of

technical committees (TCs), the OASIS board of directors has

created a Process Advisory Committee (PAC) and chartered it to

develop a set of changes to the OASIS bylaws that will provide for

easier committee maintenance. The PAC is expected to deliver a

package of proposed bylaw amendments in time for distribution at

the OASIS meetings to be held in conjunction with the Paris XML

Europe conference in June 2000.

In the meantime, the OASIS board, with the advice of the PAC, has

created a temporary set of procedures for TCs based on the default

Robert's Rules process specified by the current corporate bylaws.

The complete interim procedure for the creation of an OASIS TC can

be found at

[THIS LINK IS NO LONGER GOOD; but we can get information on the outcome of this activity.]

(the balance of the article described the initial proposal for quorum and gave a short history of Robert’s Rules.)

rev. 1/24/01: scheduling of joint meetings, who represents the TC/SIG? (came up in room balancing call -- cat fight between Stan, Ed, ???)