Re: Default Process: Other Committees

[Paul Grosso <pgrosso@arbortext.com>]

At 10:33 1999 11 15 -0800, Jon Bosak wrote:
>| 1. Committee versus subcommittee:

[various quotes with sometimes contradictory terminology...]
 
>Unless someone can dig out evidence to the contrary (go for it), I
>believe that we've always had multiple technical committees, not
>subcommittees, loosely organized into a technical track, not a
>Technical Committee.  But Paul Grosso's on this list, so I'll just ask
>him -- does that accord with your recollection, Paul?

We (myself included) tended to use the terminology loosely, 
especially at the beginning, but the idea was always as follows.

There was a Marketing Track and a Technical Track.  "Track" was
never well-defined.  The Marketing Track had several (on the order
of three, I believe) standing committees.  

The Technical Track had a single Technical Committee.  We even called
it the "committee of the whole" sometimes, which I believe is a
Roberts-ism; other times we referred to it as the plenary.  Voting always 
occurred at that level, and one could be a member of the Technical 
Committee itself without being in any of the subcommittees.  This
Technical Committee was the only thing in the Technical Track with
a standing standing.  The Technical Committee could decide to create
subcommittees that would have a certain task and would disappear when
the task was done.  At first, subcommittees were formed when we had
a topic, and they would just start work.  Later, we tried to get a
bit more formal about starting them up.  Though I know this organization
was described back in 1994 (and perhaps even 1993), I managed to put
my hands on a writeup that described the "more formal guidelines" that
we put into practice in November 1995.  The rest of this message after
my signature is a copy of that message.

>But gosh, this sure goes a long way out on a logical limb.  Does
>anyone remember whether our technical committees were created by
>action of the board, or by action of the membership acting in
>assembly? 

The Technical Committee just always existed.  The subcommittees
were created by the Technical Committee, though we usually didn't
vote on it, we just created a new subcommittee by consensus of
the Technical Committee and by the fact that we had some volunteers.
The "formal guidelines" define the more formal methods we adopted
for creating new subcommittees.

paul

---------------------------------------------


>From sgmlopen@prep.net Fri Nov 17 15:12:59 1995
Date: Fri, 17 Nov 1995 14:26:49 -0500
From: sgmlopen@prep.net (SGML Open)
To: associates@sgmlopen.org, sponsors@sgmlopen.org, subscribers@sgmlopen.org,
    techcte@sgmlopen.org
Cc: geyer@sgmlopen.org
Subject: IMPORTANT: Guidelines for SGML Open Technical Track Activities

To:     SGML Open Sponsors, Associates, and Subscribers
From:   Paul Grosso, Chief Technical Officer
=============================================================================

As part of our ongoing attempt to improve the effectiveness of SGML
Open's committee work, the SGML Open Board of Directors has formalized
our guidelines for the organization of SGML Open Technical Committee work.
This message describes how the Technical Track has incorporated the latest
process improvements.

The guidelines discuss:

* The development of charters for each subcommittee.

* The use of discussion groups as precursors to subcommittees and as
  alternatives to subcommittees for certain purposes.

* The clear definition of types of formal output from the Technical Track,
  including Technical Resolutions, Technical Research Papers, and Technical
  Memorandums.

The guidelines and process improvements described below will be reviewed
during the Consortium's Annual General Membership meeting, scheduled for
Thursday, December 7, 1995, at 4:00 pm at the Sheraton Hotel and Towers.
In the meantime, however, please don't hesitate to contact me if you have
questions, issues, or concerns.

Paul

Paul Grosso, Chief Technical Officer, SGML Open
E-mail:  paul@arbortext.com
=========================================================================

                           Technical Track Overview
                           ========================
                               17 November 1995

Participation in Technical Committee work is open to all sponsor and
associate members (and sponsor members are reminded that participation
on the Technical Committee is part of their membership responsibilities).
All Technical Track work is performed under the auspices of the
Technical Committee as a committee of the whole, and, while subcommittees
and discussion groups may be formed as a practical consideration, any
work that is the consensus of any subcommittee or discussion group is
considered to be a work of the entire Technical Committee.

The Technical Committee has no standing subcommittees.  A subcommittee
is formed to accomplish a defined task and is suspended or disbanded
when it has no more tasks on its list.  Every subcommittee has a short
term goal and possibly medium and long term goals.  The short term
goal should have approximately a six month timeframe.

Charters
========

Each subcommittee maintains a specific "charter" document.  Part of
the process of constituting a new subcommittee should be the development
of a charter that defines the subcommittee's goals, deliverables, and
timeframes.  As a subcommittee progresses through its work, it should
keep the charter document up to date.  A clear charter for each
subcommittee should help both to focus subcommittee activities as well
as to give milestones against which to measure progress.  It will also
help increase the communication among SGML Open members and allow for
greater synergy between the Marketing and Technical tracks.

Technical Track Output
======================

SGML Open Technical Committee output includes the following documents:

* a Technical Resolution (TR) for things that require work by our members to
  support,

* a Technical Research Paper (TRP) for things that report
  status/survey/research results that don't require work by our members to
  support but that might lead to a TR and/or otherwise make public some
  SGML Open position or statement that requires acceptance by members in
  general before making public, and

* a Technical Memorandum (TM) for other output from the Technical Committee
  that reflects agreement among the Technical Committee but does not require
  formal acceptance by members in general.

We have a two-month ballot period for TRs and a six-week ballot period for
TRPs, and each ballot requires two-thirds of the votes cast to be accept
or accept with comments to pass.  There is no vote on TMs.

Discussion Groups
=================

Our Technical Track guidelines also allow for a discussion group which,
while not yet formalized into a subcommittee, may decide to develop a
charter and become a subcommittee.  Only subcommittees can produce SGML
Open Technical Committee deliverables.  Discussion groups are formed to
determine if there is interest in a topic and if there is something
that is appropriate for SGML Open to address with respect to that
topic.  Discussion groups can be a forum for SGML Open members to
discuss issues that may not lead to SGML Open deliverables -- for example,
to evaluate some industry DTD or discuss some political issue.  However,
no part of the discussion within a discussion group can be reported in
any forum as the consensus of SGML Open as a group.  As soon as it appears
likely that a group discussion may lead to some sort of SGML Open
deliverable, the group should generate a charter and become a subcommittee.

No discussion of a topic preceding the formation of a subcommittee
is to be assumed once the subcommittee is formed.  However, once a
subcommittee is duly formed, it becomes the SGML Open member organization's
responsibility to participate in the ongoing discussion in a timely manner
to whatever extent desired.  During the subcommittee discussion, the
subcommittee chair or the Chief Technical Officer may deem comments of a
divergent nature that appear late in a discussion or that are outside the
scope of the discussion as defined by the charter to be out of order for
the current discussion (though perhaps valuable for a follow up goal for
that or another subcommittee).

Process Benefits and Results
============================

The discussion group and charter development methodology implements a
process which should help us better understand our objectives as we develop
solutions.  Since Technical Resolutions may require member development and
implementation support, it is critical that we get members involved early
in the process.  By developing charters, members will be better able to
determine early on in the process what the impact will or might be to their
own products.  As a result, those affected will be able to commit resources
to helping SGML Open with that particular endeavor.  This approach should
make it easier for member companies to keep up to date with our efforts.

It is the responsibility of each member to be aware of and involved in any
technical discussion to the extent they wish to be involved.  It is to
everyone's advantage when there is a high level of participation throughout
the entire life cycle of a technical discussion.  Periodic updates of
Technical Committee work in progress and upcoming topics are distributed
to the techcte@sgmlopen.org mailing list.  Every member company should be
sure to have at least one designated person whose current email address
is included on that list.

Current Committees and Discussion Groups
========================================

Presently, the SGML Open Technical Committee has two active subcommittees:
the Table Interoperability subcommittee and the Fragment Interchange
subcommittee.  (The Entity Management subcommittee has no tasks on its
list and is currently suspended; if an issue comes up that is appropriate
to that subcommittee, it may reconstitute itself with the formulation of
a new charter.)

The following is the list of current (some more active than others)
discussion groups:  SGML and the Internet, Style Interchange, Digital
Signatures.  (Other suspended groups include Parser compatibilities,
character set issues, and SGML database/query language.)  The goal of
each of these groups is to determine what the key issues are and what
if anything SGML Open can and should do in that area.  Any of these
groups can develop a charter and submit it to the SGML Open Board of
Directors; if the charter is accepted, then that group would become a
subcommittee.

==============
End of message