Re: [mpowr] WG Formation

[Thomas Narten <[e-mail]>]

> The IETF is good at facilitating working groups that have clear,
> practical direction, with significant participation and an ability to
> conduct productive discussion in a timely fashion.

Note: as an AD, I find that making the judgement call as to whether an
effort (e.g., BOF preparation and/or mailing list BOF preparation) is
actually a "productive discussion" is not always so easy, and that my
assessment is frequently at odds with that of those participating in
or driving the effort. There are multiple dimensions here. Ability to
articulate the root problem. Ability to see potential solutions that
solve the exact problem (and no more). Willinginess to keep the
solution simple. Willingness (or ability) to see implications of a
particular approach on other parts of the Internet which are not an
immediate focus of the WG. Etc.  And because there is a judgement call
(on which different people may not agree) on many of these points,
coming up with clear criteria that folks will generally agree on is
probably not so easy.

> The IETF has a poor track record of "fixing" broken working groups. In
> particular, working groups that lack cohesive, productive discussion
> rarely change.

> Problematic working groups are a significant drain on IETF resources,
> including time for management oversight, consumption of valuable
> participant time, and consumption of scarce meeting time. Problematic
> working groups also have an opportunity cost. They set expectations for
> a solution that is, in fact, unlikely to be produced in a timely or
> useful fashion.

> It is to the IETF's general benefit to find ways to avoid this waste of
> resources and tone of frustration and non-productivity.

I suspect everyone would agree that finding a way to address this
would be good!

> One approach that will help is to require that working group formation
> be predicated on a demonstrated ability to conduct productive discussion
> over a mailing list and with enough participation to demonstrate
> meaningful constituency.

I think that in practice this is already being done. I'd be interested
in hearing of specific cases where it is not. But as I said earlier,
people's views of "productive" vary, so in the end there is often a
judgement call that has to be made.

As one example (since folk here probably aren't aware of it...) Some
folk asked for an anycast BOF for the upcoming IETF. The RTG and INT
ADs were involved. We basically said no, because we weren't convinced
that enough prep work had been done for a BOF, even though the
proponent(s) probably felt otherwise. We specifically wanted more
mailing list discussion, a more clear problem statement and IDs. But
they did have a mailng list, a proposed charter and pointed to a
number of IDs... 

> This _adds_ to the list of IETF BOF and working group chartering
> pre-requisites. It requires that groups expected to be productive and
> timely first show that they can be. In fact, this requirement is already
> listed as being optional, in RFC 2418 (IETF Working Group Guidelines and
> Procedures), before holding a pre-chartering BOF.

> So the only change would be to make it always required, before
> chartering and before holding a pre-chartering BOF.


> An alternative would be to continue to charter working groups that lack
> a track record for timely productivity, and continue to task the working
> group chairs and cognizant area director with fixing the working groups
> that fail to become coherent and productive in a timely fashion.

One thing the above doesn't help with is work areas where there are
clearly folk interested in working on the problem, the problem is
real and in need of a solution, but the effort needs help getting on
track. Is it better to work with the group within the IETF? Or to keep
them at arms length outside and hope the can figure things out for
themselves?

I think the answer depends on many factors, but when the problem is of
importance to the IETF, and there is enough activity going on that if
the IETF ignores it, it will have to deal with the consequences later
anyway, keeping them at arms length doesn't seem like the better
alternative.

> Over the life of the IETF, some area directors have employed the policy
> of requiring a group to demonstrate the requisite capabilities, before
> chartering as an IETF working group.  In fact, some area directors have
> required this before permitting a BOF to be held.  A BOF session is
> very short and BOFs drain from the total pool of congested IETF
> meeting time.

Speaking personally, I've certainly hosted a number of BOFs that
didn't seem like they were that well run or had prepared
adequately. At the same time, those efforts usually did have a fair
amount of behind-the-scene steering/encouragement from the ADs (and
others) trying to make them better and good enough. But at the end of
the day the question is: is the community better served by letting the
BOF (with whatever shortcomings) go forward, or should it be delayed
for at least another cycle in attempt (hope?) to make things more
baked? Pushing off a BOF for another cycle has the downside of
delaying an effort and/or opening the AD up to criticism that they
just don't (for whatever reason) like the BOF (or an ID, or  a
particular solutions, or...).

> The suggestion is to move this requirement from "sometimes" to "always",
> just as we always require a coherent charter with constituency support,
> before creating a working group.

I certainly look for this before creating a WG. Among the factors I
look for:

 - clear problem statement? Well-scoped and understood? (and is it
   written down so folk are agreeing to the same words?)
 - Is the problem important?
 - Is there really a need for a standard? (I.e., multiple vendors will
   need to implement this, solves an end-user problem)
 - are there sufficient worker bees? (editors, chairs, etc)
 - are the sufficient reviewers (with necessary expertise)?
 - do the participants seem to be largely in agreement on what the WG
   needs to do and how to get there? (or will this group be hard to
   manage and keep on track)?
 
> This moves the responsibility for timely productivity entirely to the
> nascent working group, rather than imposing any of that requirement on
> IETF management.

Certainly, there is a time for this. But I think there are too many
differences in each BOF situation to make hard-and-fast rules that
MUST be adhered to.

Thomas

_______________________________________________
mpowr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpowr