ietf
[Top] [All Lists]

Re: improving WG operation (was Re: Voting (again))

2005-04-29 19:28:02
John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:

Going back almost to the dawn of IESG time, the IESG has had one
constant and primary responsibility.  That is to manage the WGs
and the WG process.  Under today's rules, they determine or
ratify which WGs get created, who chairs them and how they are
otherwise managed, what tasks and benchmarks go into charters,
how many and which documents a WG can work on at a time (and
whether they work on documents serially or in parallel), and
when to shut them down.  They have _huge_ latitude in how to
manage WGs and the decisions they make about that management
process, including a wide range of options about reporting,
review of benchmarks, actions or the lack thereof when targets
are not met, and so on.

   You've covered an awful lot of territory there:

- creating / shutting down WGs -- clearly must be IESG responsibility.
- who chairs WG -- feels more like an Area Director responsibility.
  The IESG should require ADs to report on WG progress; the AD should
  have the right to deal with WG chairs s/he trusts.
- how they are otherwise managed -- whazzat?
  WG chairs should be responsible to ADs. End-runs around WGCs (other
  than formal appeals) tend to be harmful.
- what goes into charters -- the IESG must take responsibility for the
  initial charter, but not all updates should need IESG action.
- how many documents a WG can work on -- silly-season...
  Clearly, taking on a new task should be a charter revision, which
  might require IESG action; but splitting a task between two Document
  Editors shouldn't even require notice to the AD.
- whether documents can be worked on in parallel -- micromanagement.
  For the AD to specify this would be seriously unwise: for the IESG
  to even talk about it is a waste of time or worse.

WGs, and WG leadership, have no independent existence: the IESG,
and under some circumstances, individual ADs can dispose of them
as needed.

   I've never been comfortable with the idea that the IESG can "solve"
a problem by dissolving a WG. That said, there is a clear need for
something like a probationary status, where a WG loses (temporarily)
its right to submit documents as WG submissions until some defect is
corrected; and at some point, actually loses its right to any AD
oversight at all.

   IMHO, "surprise" dissolutions of WGs are not helpful.

Personally, I think that is as it should be.  While the
community has periodically discussed constraints on WG behavior
and management (including one or two that I have written), none
have ever been approved: the IESG continues to be able to look
at WGs and their work on a case-by-case basis and to make
case-by-case decisions.  My personal view is that they (the
IESG) should have a little more guidance from the community to
aid them in making tough decisions and to assure them of backing
when such decisions are made, but that wouldn't change the
essential nature of the situation very much.

   I'm not really sure what the community _could_ do to offer much
guidance here; and I don't think community "support" of IESG decision
has much meaning. The question is whether an IESG action is going to
result in a long-winded appeal process; and there's remarkably little
that anyone can do about that.

But, from that perspective, there is no "WG problem" or "problem
WG".  There is only an IESG management problem.  Either the
number and complexion of WGs is such that the IESG can manage
them effectively, or it isn't.  If it isn't, only the IESG can
be responsible.

   Except that I see the bottleneck at the AD/WGC interface, I agree.

Either WGs are sufficiently well chartered and managed so that the
review processes we have work adequately well or they aren't.
Either way, the IESG bears ultimate responsibility: they determine
the charters, the management structure, the review requirements or
lack thereof at various intermediate points, and so on.

   I'm not sure it's helpful to look at it that narrowly.

   I think I quite agree with John Klensin that if charters, structure,
and review requirements are done right, corrective actions will become
obvious. I don't agree, however, that our selection process for IESG
members does anything to ensure sufficient expertise to get charters,
structure, and review requirements right on the first try.

   I think we need a mechanism to notice that something needs correction,
and get independent review of charters, structure, and review requirements
when problems appear.

Now, it is reasonable to say "the IESG doesn't have bandwidth to
do that job well and still review documents for standardization".

   Certainly a reasonable question: but I don't choose to give an
opinion on it at present...

But it doesn't seem to me that saying "we have all of these out
of control WGs and need to concentrate on fixing them and not on
looking at the IESG" or even "focus our attention on WG
operation" is productive: if the WGs are not under control,
then, IMO, the IESG, as the body with the management
responsibility, needs to acknowledge that fact and then either
needs to fix it or make suggestions to the community as to how
we can fix it together.  If they are not convinced that "working
group operations" is the problem, then there is either no
problem or an IESG problem.

   This view is entirely too "top-down".

   Obviously, both WG-problems and problem-WGs exist: almost as obviously,
the problems are not all the same. It's fine to say that in theory, all
these problems belong to the IESG: but it's not particularly helpful.
If we expect the IESG to fix all WG problems, we severly constrain the
number of WGs we can have -- leaving no satisfactory method for getting
increasing amounts of work done.

   The _best_ this view has to offer is stagnation. :^(

   If, instead, we view the situation as groups of folks that want to work
on problems, and the _issue_ as whether they should associate with IETF
or work somewhere else, I believe much more can be accomplished.

--
John Leslie <john(_at_)jlc(_dot_)net>

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf