Re: A very late suggestion (was; Re: [art] Back from leave)

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

 




--On Tuesday, October 25, 2022 11:26 +0300 Lars Eggert
<lars@xxxxxxxxxx> wrote:

> Hi,
> 
> On 2022-10-24, at 20:45, John C Klensin <john-ietf@xxxxxxx>
> wrote:
>> we add a third ART AD slot and add it as close to
>> Right Now as possible. By the numbers alone and just dividing
>> the number of WGs in the area by two, the ART ADs are
>> responsible for more WGs than ADs in any other area.
> 
> there are other considerations of course, such as the number
> and length of documents produced, etc., not to speak of taking
> on other roles or tasks for the IESG.

Of course.  I did not intend to oversimplify things.  Addressing
that one consideration as an example, I'm part of a WG that
should be dropping a pair of documents, one 56 pages long and
one that will push 100 (ignoring the index and after all of the
tracking material is removed).  That is just one, anecdotal
case, but I don't think ART has a shortage of very long and
complex documents.  On the other hand, those issues, also
including ADs expecting too much of themselves, notwithstanding,
the very large number of WGs in the Area, much larger than even
Routing with three ADs seems fairly compelling.

Drawing a bit on Michael's comment about 50% of an 80 hour week,
I also think (and have thought for many years) that we should be
looking at ways to reduce the workload, possibly including
reexamining the long-ago proposals to put ceilings on the number
of WGs and asking hard questions about what ADs do not need to
do.     In addition to the obvious effect, reducing the real and
perceived workload (and other costs of being an AD) might
increase the candidate pool.   I wonder if the lack of other
candidates for the ART position that Francesca mentioned is due
to people being unwilling to put their names in against a
first-term incumbent who is widely perceived as having been
successful and effective and/or distaste of being in the
position of apparently wanting to displace a woman with an
infant child.   If so, the IESG opening up a third ART AD slot
might help with that problem as well but obviously would need to
be done very, very, soon.

> I do like the suggestion to have some sort of community
> expectation on what a reasonable workload for an AD is, and
> what the relevant metrics could be.

Indeed, a good idea although not one that would likely produce
results, e.g., this month.
 
> I would want to point out though that growing the IESG does
> have a cost, because we expect all ADs to ballot on documents,
> and that means additional comments and potentially discusses.
> And a larger IESG has a larger management overhead and
> establishing consensus internally may become more difficult.

Absolutely.  And that was one of the reasons for the push, many
years ago, to limit the number of WGs.  If we keep the size of
the IESG constant, or even shrink it, without reducing the
number of WGs we approve (or allow to continue for a long time),
expecting all ADs to ballot on documents just drives the per-AD
workload up.  So that may be very nearly a "lose either way"
situation unless the community is willing to accept a higher
threshold for starting and continuing WGs.  Many years ago, we
had the view that long-lived WGs were, with few exceptions, a
bad idea.  Now it seems to be common for them to be very
long-lived, passed from ADs to their successors more than once
(I have not checked the data; that is just an impression).    I
have no opinion as to whether this would be a good idea --it
would certainly increase the workload for at least a while-- but
how would the IESG feel about sunset provisions for WGs,
requiring not only rechartering but a review of how the value of
their work should rank them in priority for resources within an
Area?

thanks,
    john




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

  Powered by Linux