RE: WG Chairs Training

[Black_David@emc.com]

Spencer,

Some of the suggestions don't quite match up to RFC 2418.
There are a few constraints:
- A document editor who doesn't edit the document to reflect
	WG consensus needs to be replaced with one who does.
	WG chairs have the power to do this, but it needs to
	be used sparingly to be effective.
- A document editor working on a draft as an individual should
	be by default rather than design.  This might happen when
	there's little active interest in the WG, but the work
	needs to be done.
- Design teams are closed forums whose output is necessarily
	subject to further open review by the WG.  While
	design team membership can be artfully selected with
	the intent of driving compromise among diverging
	positions, the WG has the final authority to reject
	the result as an unacceptable compromise.

Thanks,
--David

> OK, this is very fair.
> 
> I don't want to generate lots of process work, but is it worth
> having a checklist for each working group that says (for
> instance)
> 
> "When our working group adopts this draft (check one):
> 
> - the editor needs to reflect working group consensus
> - the editor needs to reflect working group consensus
>   but may be asked to present strawperson roadblock-breaker
>   text if we need it
> - the editor is allowed to make structural changes,
>   but not technical changes
> - the editor is allowed to continue to work on the draft
>   as an individual"
> 
> Just so we make some choices explicit and remove surprises when
> an editor DOES continue to work on a working group draft as an
> individual - which I'm not sure is ALWAYS a bad thing, just when
> 
> it's a surprise?
> 
> Another might be
> 
> "This design team will provide a draft that (choose one):
> 
> - will be evaluated as any other non-working group draft
> - will be accepted because we're putting the design team
>   together to make a binding choice
> - will be accepted as working group baseline text, and then
>   we'll make changes required for working group acceptance"
> 
> All of which are situations I've observed with design teams in
> the past.
> 
> And we could start making up the checklist as we go, and have a
> pretty good one in a couple of years without a big effort now.
> 
> I've seen a couple of posts on this list from chairs who said
> they didn't realize what choices they were making implicitly (by
> 
> saying nothing), and I've been there, too, so -
> 
> I appreciate Thomas's support for flexibility and trust of WG
> chairs, I'm just thinking about WG chairs who may not realize
> when someone is trusting them to do the right thing in a
> specific situation.
> 
> Spencer
> 
> --- Thomas Narten <narten@us.ibm.com> wrote:
> >
> > IMO, consistency is generally good. But we also need
> > flexibility.
> >
> > At a minimum, it would be good if folk understood the issues
> > related
> > to process issues, and how poor implementation of internal
> > processes
> > has led to plenty of real process/WG problems and how better
> > execution
> > of internal processes can really help to avoid such problems.
> > Giving
> > examples of the kinds of problems that can and have occurred
> > is often
> > illuminating, especialy when folk don't have so much direct
> > experience
> > themselves.
> >
> > Armed with such a background, we also need to allow chairs
> > some
> > flexibility in tailoring internal procesesses to the specific
> > situation of individual WGs.
> >
> > What needs to be clear though is that it is the responsibility
> > of the
> > chairs to minimize process problems, with failure to do so
> > having the
> > obvious unfortunate consequences.
> >
> > Thomas
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
> 
> 
>