Subject: Voting and WG Chair role

From: [email-masked]
Date: Thu, 19 Dec 2002 20:35:20 -0500

> >I certainly saw a careful count of raised hands in Atlanta over
> >the V6 site-local issue, so on the one (raised) hand we already have
> >some form of expression of group consensus by simple numbers
> >(voting) happening already in some working groups.
> 
> I wouldn't describe what we did as a "careful" count (I know,
> because I was doing some of the counting), but we did count.

While I ask attendees to raise hands in WG meetings from time to time,
it would be wrong to confuse that with the sort of formal votes that
go on in other standards organizations.  In particular, I don't try
this if I have any reason to believe that "ballot box stuffing" is
a possibility, and I usually don't count - if the "sense of the room"
isn't obvious from the relative number of raised hands, the result's
not "rough consensus" and the issue probably needs more thought and
discussion.  

> So, which of the following jobs would you assign to a WG chair:
> 
>          (1) Drive the process to produce the best technical
>                  result, and send that result to the IESG, or
>          (2) Manage a process that is driven by the consensus
>                  of the WG, make sure that the documents
>                  pass ID-nits, and send the consensus result
>                  to the IESG?

I'm definitely a class (1) chair, and believe that's the proper
role - I have no problem driving one person's objection to what
appears to be WG consensus through the WG because the objector has
an important point that nobody's paying attention to.  OTOH, I also
have no problem in liberally wielding the proverbial clue-by-four
to put bad ideas out of their misery early in the process rather
than later.  I think this sort of WG chair activity is important, as
resolving these issues directly in a WG is far more effective than
forcing the ADs and IESG to spend time on clear cases of "clue
impairment".

A risk that's been observed earlier is that a class (1) chair can
get sufficiently involved in a technical issue to make it hard to
fairly call the rough consensus on that issue.  Having two chairs,
where one makes sure to stay out when the other dives in works
well, and beyond that it's a matter of careful exercise of
judgment to try to avoid having to be bailed out by the AD
(how embarrassing ...).

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 20 Dec 2002 11:00:48 -0500

>>                  pass ID-nits, and send the consensus result

When I was IPsec co-chair, I fit category (1).  This was NOT the most
popular approach, but was really the only option.  Had I taken category
(2)
with IPsec WG in the mid-90s, the WG would not have gotten anywhere.
One result,
in the case of IPsec, was that I got burned out and quit as co-chair
(giving
the ADs ample advance notice so they could arrange for a smooth
transition
to new chairs).

When I was OTP co-chair, both co-chairs fit category (2).  And given
the small, focused, and clueful nature of the OTP WG participant set,
that was the right choice for that WG.  The current NFS co-chairs
seem to be using (2), and that seems wildly successful for NFS WG.

Bottom line is that different WGs likely need different approaches.
And there might be some 3rd or 4th approach not enumerated above
that would also fit in some situations.

Ran
[email-masked]