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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John C Klensin <john-ietf@xxxxxxx> 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@xxxxxxx>

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]