Re: [wg-c] co-chair

[Kent Crispin <kent@songbird.com>]

On Fri, Jul 23, 1999 at 07:13:09PM -0400, Rod Dixon wrote:

> I suggest, however, that we first determine what exactly the role of the
> chair is going to be along with what effect having two chairs will have
> on the role of the chair. I suppose that it is appropriate to have
> anyone who has been nominated (or has accepted a nomination) for
> chair/co-chair could explain what is it that we are electing them to do. 

From my perspective you are electing the chair to do a job very
similar to what the WG chair in the IETF does.  The IETF has been
running on-line decision processes longer than just about anyone, and
they have distilled a wealth of experience about what works.  As
pointed out the workings of IETF WGs are described in rfc 2418.  I
propose that we follow that document to the extent that it applies,
with appropriate substitutions (eg "Names Council" for "Area
Directors", and so on).  

The document leaves the workings of the WG mostly to the WG, but
makes a number of suggestions for the functions of the WG chair.

Here are some relevant sections:

  2. Working group formation

  IETF working groups (WGs) are the primary mechanism for development
  of IETF specifications and guidelines, many of which are intended to
  be standards or recommendations. A working group may be established
  at the initiative of an Area Director or it may be initiated by an
  individual or group of individuals. Anyone interested in creating an
  IETF working group MUST obtain the advice and consent of the IETF
  Area Director(s) in whose area the working group would fall and MUST
  proceed through the formal steps detailed in this section.

[...]

  3.  Working Group Operation

  The IETF has basic requirements for open and fair participation and
  for thorough consideration of technical alternatives.  Within those
  constraints, working groups are autonomous and each determines most
  of the details of its own operation with respect to session
  participation, reaching closure, etc.  The core rule for operation
  is that acceptance or agreement is achieved via working group
  "rough consensus".  WG participants should specifically note the
  requirements for disclosure of conflicts of interest in [2]. 

  A number of procedural questions and issues will arise over time,
  and it is the function of the Working Group Chair(s) to manage the
  group process, keeping in mind that the overall purpose of the
  group is to make progress towards reaching rough consensus in
  realizing the working group's goals and objectives. 


[The following paragraph is the most important, probably:]

  There are few hard and fast rules on organizing or conducting
  working group activities, but a set of guidelines and practices has
  evolved over time that have proven successful.  These are listed
  here, with actual choices typically determined by the working group
  participants and the Chair(s). 

[...]

  NOTE: While open discussion and contribution is essential to
  working group success, the Chair is responsible for ensuring
  forward progress.  When acceptable to the WG, the Chair may call
  for restricted participation (but not restricted attendance!) at
  IETF working group sessions for the purpose of achieving progress. 
  The Working Group Chair then has the authority to refuse to grant
  the floor to any individual who is unprepared or otherwise covering
  inappropriate material, or who, in the opinion of the Chair is
  disrupting the WG process.  The Chair should consult with the Area
  Director(s) if the individual persists in disruptive behavior. 

   On-line

  It can be quite useful to conduct email exchanges in the same
  manner as a face-to-face session, with published schedule and
  agenda, as well as on-going summarization and consensus polling. 
  Many working group participants hold that mailing list discussion
  is the best place to consider and resolve issues and make
  decisions.  The choice of operational style is made by the working
  group itself.  It is important to note, however, that Internet
  email discussion is possible for a much wider base of interested
  persons than is attendance at IETF meetings, due to the time and
  expense required to attend. 


  As with face-to-face sessions occasionally one or more individuals
  may engage in behavior on a mailing list which disrupts the WG's
  progress.  In these cases the Chair should attempt to discourage
  the behavior by communication directly with the offending
  individual rather than on the open mailing list.  If the behavior
  persists then the Chair must involve the Area Director in the
  issue.  As a last resort and after explicit warnings, the Area
  Director, with the approval of the IESG, may request that the
  mailing list maintainer block the ability of the offending
  individual to post to the mailing list.  (If the mailing list
  software permits this type of operation.) Even if this is done, the
  individual must not be prevented from receiving messages posted to
  the list.  Other methods of mailing list control may be considered
  but must be approved by the AD(s) and the IESG. 

[...]

  3.3.  Session management

  Working groups make decisions through a "rough consensus" process. 
  IETF consensus does not require that all participants agree
  although this is, of course, preferred.  In general, the dominant
  view of the working group shall prevail.  (However, it must be
  noted that "dominance" is not to be determined on the basis of
  volume or persistence, but rather a more general sense of
  agreement.) Consensus can be determined by a show of hands,
  humming, or any other means on which the WG agrees (by rough
  consensus, of course).  Note that 51% of the working group does not
  qualify as "rough consensus" and 99% is better than rough.  It is
  up to the Chair to determine if rough consensus has been reached. 

  It can be particularly challenging to gauge the level of consensus
  on a mailing list.  There are two different cases where a working
  group may be trying to understand the level of consensus via a
  mailing list discussion.  But in both cases the volume of messages
  on a topic is not, by itself, a good indicator of consensus since
  one or two individuals may be generating much of the traffic. 

  In the case where a consensus which has been reached during a face-
  to-face meeting is being verified on a mailing list the people who
  were in the meeting and expressed agreement must be taken into
  account.  If there were 100 people in a meeting and only a few
  people on the mailing list disagree with the consensus of the
  meeting then the consensus should be seen as being verified.  Note
  that enough time should be given to the verification process for
  the mailing list readers to understand and consider any objections
  that may be raised on the list.  The normal two week last-call
  period should be sufficient for this. 

  The other case is where the discussion has been held entirely over
  the mailing list.  The determination of the level of consensus may
  be harder to do in this case since most people subscribed to
  mailing lists do not actively participate in discussions on the
  list.  It is left to the discretion of the working group chair how
  to evaluate the level of consensus.  The most common method used is
  for the working group chair to state what he or she believes to be
  the consensus view and.  at the same time, requests comments from
  the list about the stated conclusion. 

  The challenge to managing working group sessions is to balance the
  need for open and fair consideration of the issues against the need
  to make forward progress.  The working group, as a whole, has the
  final responsibility for striking this balance.  The Chair has the
  responsibility for overseeing the process but may delegate direct
  process management to a formally-designated Facilitator. 

  It is occasionally appropriate to revisit a topic, to re-evaluate
  alternatives or to improve the group's understanding of a relevant
  decision.  However, unnecessary repeated discussions on issues can
  be avoided if the Chair makes sure that the main arguments in the
  discussion (and the outcome) are summarized and archived after a
  discussion has come to conclusion.  It is also good practice to
  note important decisions/consensus reached by email in the minutes
  of the next 'live' session, and to summarize briefly the
  decision-making history in the final documents the WG produces. 

  To facilitate making forward progress, a Working Group Chair may
  wish to decide to reject or defer the input from a member, based
  upon the following criteria:

   Old
   The input pertains to a topic that already has been resolved and is
   redundant with information previously available;

   Minor
   The input is new and pertains to a topic that has already been
   resolved, but it is felt to be of minor import to the existing
   decision;

   Timing
   The input pertains to a topic that the working group has not yet
   opened for discussion; or

   Scope
   The input is outside of the scope of the working group charter.

[...]

  6.1.  WG Chair

  The Working Group Chair is concerned with making forward progress
  through a fair and open process, and has wide discretion in the
  conduct of WG business.  The Chair must ensure that a number of
  tasks are performed, either directly or by others assigned to the
  tasks. 

  The Chair has the responsibility and the authority to make
  decisions, on behalf of the working group, regarding all matters of
  working group process and staffing, in conformance with the rules
  of the IETF.  The AD has the authority and the responsibility to
  assist in making those decisions at the request of the Chair or
  when circumstances warrant such an intervention. 

  The Chair's responsibility encompasses at least the following:

  Ensure WG process and content management

      The Chair has ultimate responsibility for ensuring that a working
      group achieves forward progress and meets its milestones.  The
      Chair is also responsible to ensure that the working group
      operates in an open and fair manner.  For some working groups,
      this can be accomplished by having the Chair perform all
      management-related activities.  In other working groups --
      particularly those with large or divisive participation -- it is
      helpful to allocate process and/or secretarial functions to other
      participants.  Process management pertains strictly to the style
      of working group interaction and not to its content. It ensures
      fairness and detects redundancy.  The secretarial function
      encompasses document editing.  It is quite common for a working
      group to assign the task of specification Editor to one or two
      participants.  Sometimes, they also are part of the design team,
      described below.

   Moderate the WG email list

      The Chair should attempt to ensure that the discussions on this
      list are relevant and that they converge to consensus agreements.
      The Chair should make sure that discussions on the list are
      summarized and that the outcome is well documented (to avoid
      repetition).  The Chair also may choose to schedule organized on-
      line "sessions" with agenda and deliverables.  These can be
      structured as true meetings, conducted over the course of several
      days (to allow participation across the Internet).

      Organize, prepare and chair face-to-face and on-line formal
      sessions.

   Plan WG Sessions

      The Chair must plan and announce all WG sessions well in advance
      (see section 3.1).

   Communicate results of sessions

      The Chair and/or Secretary must ensure that minutes of a session
      are taken and that an attendance list is circulated (see section
      3.1).

      Immediately after a session, the WG Chair MUST provide the Area
      Director with a very short report (approximately one paragraph,
      via email) on the session.

   Distribute the workload

      Of course, each WG will have participants who may not be able (or
      want) to do any work at all. Most of the time the bulk of the work
      is done by a few dedicated participants. It is the task of the
      Chair to motivate enough experts to allow for a fair distribution
      of the workload.

   Document development

      Working groups produce documents and documents need authors. The
      Chair must make sure that authors of WG documents incorporate
      changes as agreed to by the WG (see section 6.3).

  6.2.  WG Secretary

  Taking minutes and editing working group documents often is
  performed by a specifically-designated participant or set of
  participants.  In this role, the Secretary's job is to record WG
  decisions, rather than to perform basic specification. 

  6.3.  Document Editor

  Most IETF working groups focus their efforts on a document, or set
  of documents, that capture the results of the group's work.  A
  working group generally designates a person or persons to serve as
  the Editor for a particular document.  The Document Editor is
  responsible for ensuring that the contents of the document
  accurately reflect the decisions that have been made by the working
  group. 

  As a general practice, the Working Group Chair and Document Editor
  positions are filled by different individuals to help ensure that
  the resulting documents accurately reflect the consensus of the
  working group and that all processes are followed. 

  6.4.  WG Facilitator

  When meetings tend to become distracted or divisive, it often is
  helpful to assign the task of "process management" to one
  participant.  Their job is to oversee the nature, rather than the
  content, of participant interactions.  That is, they attend to the
  style of the discussion and to the schedule of the agenda, rather
  than making direct technical contributions themselves. 

-- 
Kent Crispin                               "Do good, and you'll be
kent@songbird.com                           lonesome." -- Mark Twain