Re: COACH BoF

[margaret.wasserman@comcast.net]

> >> What isn't clear to me is: where from here.  There seemed to be
> >> a theory that this might be a working group, but it's not clear
> >> to me that there is on-going working group material here (rather
> >> than a good venue for discussing some point solution ideas).
> >
> > My concern is that some of the suggestions introduce more process, at a
> > time when I perceive the mood of the IETF to be anti-process.  We can
> > certainly assert that front-loading the process will produce better
> > documents that will clear the IESG faster, but lots of people won't
> > believe that -- witness the same discussion about software engineering.
> 
> my worry too. It was a relatively lightly attended BOF, and due to poor 
> time management, it did not give time enough to get any "sense of the room" 
> wrt whether the mood was pro-process, anti-process or mixed. There 
> certainly wasn't any great enthusiasm shown.

My guess is that there were about 50 people in the room...  I would
have preferred greater attendance, but I don't think that this 
surprisingly low.

The nature of the meeting didn't offer much opportunity for people to
express enthusiasm...  For the most part, feedback on the individual 
talks was positive, but there was no action plan presented, and the group 
wasn't asked to express an opinion on anything.  So, it is very hard 
to judge the enthusiasm level.  We may get more sense of the level of
community enthusiasm about this activity in the Problem WG and/or the 
IESG Plenary.

We have known for a long time that we have a problem with the
quality of WG work output, and that these quality problems are
causing serious problems within the IETF.  I first fully understood
this message a couple of years ago when Allison & Thomas presented
it at the IESG plenary, and the existence of this problem has been
confirmed in the problem effort.  But, there hasn't (yet) been much 
coordinated action to correct this problem.

In my opinion, there are a couple of good things we can do to
try to address the quality problem:

    - Determine what practices/processes WGs can use to 
          produce higher quality work.
    - Educate and support WG chairs in implementing those
          practices/processes.

I think that it could be a mistake to apply our usual WG creation
procedures and guidelines to the subject of process work. Standards-
oriented WGs are outward-facing -- they typically start with
work/concepts that have been developed outside the IETF framework,
and they produce standards that will be used by folks outside of
the IETF.  People are (at least partially) motivated to do standards
work by needs/priorities that exist outside the IETF, but IETF 
process work isn't like that...

We can't count on outside groups to identify IETF process problems 
or bring us work/concepts to correct them.  We have a problem that 
needs to be solved, and we need to figure out how to organize 
ourselves to solve it.  I think it would be good if we could find
a way to help/enable WG chairs to work together to solve these
problems.

So, I believe that we need some sort of coordinated function in this
area...  probably a WG.  If there is concern about too much 
process, perhaps we could limit the group to identifying the
best current practices/processes in use in our more successful
WGs, and documenting those practices/processes so that we can
use them more widely?

It doesn't seem constructive to me to continue to complain about
the quality of WG work output, if we don't (as an organization)
take some concrete steps to try to improve it...

Margaret