Re: [wg-c] co-chair

[Jonathan Weinberg <weinberg@mail.msen.com>]

	I agree with Kent.  (Gosh, how often do I say *that*?)

Jon


Jon Weinberg
weinberg@msen.com


At 05:05 PM 7/23/99 -0700, Kent Crispin wrote:
>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
>
>