Re: WG Review: General Area Dispatch (gendispatch)

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

 




--On Thursday, October 10, 2019 10:52 -0500 Ben Campbell
<ben@xxxxxxxxxxx> wrote:

>> So, the question about this proposed WG for me is whether it
>> will make those tendencies better and thereby prevent good
>> ideas from getting lost or suppressed.   If so, I think it is
>> a great idea.   But I also see the risk of its being used to
>> bury work that it out of favor with "the leadership" and
>> doing so in a way that preserves the status quo except when
>> the IESG wishes things to be different) and enables even less
>> transparency and accountability than we have seen in the
>> past.  I'd like to see ideas and controls about how to
>> prevent the latter or how to detect it and push back if it
>> starts to occur, and I don't see those in the current draft
>> specification.
> 
> Hi John,
> 
> This brings up another question in my mind. The ART ADs
> typically treat DISPATCH decisions as non-binding
> recommendations. Likewise, the ADs may skip DISPATCH and take
> proposals straight to BoF or even WG formation if they think
> it appropriate.
> 
> Would GENDISPATCH decisions be treated the same, or would they
> be binding on the IESG? I had assumed the former, in the sense
> that AD discretion applies to pretty much any working group.
> Whichever case is the answer, I think the charter needs to be
> explicit about it.

Ben,

I had assumed the former as well.  I think that taking that
discretion away from ADs would put us into a place where we
really do not want to go.  In particular, one can imagine
situations in which ADs would be forced to manage WGs they would
like to have fail and there are just too many ways in which
failures can be encouraged or the WG's work subverted.  At the
same time, we've occasionally seen that discretion used in a way
that is arguably abusive.  It is my impression that has occurred
more often with process proposals than anything else and that is
most of what prompted the note to which you responded.  

It had not occurred to me until now, but I think that concern
segues into your comments to Mark about a triage process.  If we
really mean triage, we mean something that is relatively quick
and decisive.  One of my concerns has been that the existence of
such a WG could be used to drag things out, as in "we can't
consider this until GENDISPATCH meets", then "interesting
discussion, let's postpone to the next meeting", then "this
really needs a WG for itself", then some delay in getting the WG
organized because no one on the IESG is enthused, then...   One
can easily imagine things being dragged out for close to a year,
or longer, until people lose interest or accept the status quo
as fated.  Perhaps a few guidelines and timelines would help
alleviate that concern.  For example, that the WG gets only one
shot (no postponements to the next IETF) and that, if
GENDISPATCH concludes that a WG is needed, it starts a clock
ticking by which the WG has to be either organized, formed, and
in operation or the IESG is required to explain the delay to the
community.

Probably mechanisms like that would be a net improvement over
the current situation although my concern that the IESG and the
community should watch this very carefully remains.  That
concern is especially strong if the leadership of the WG is
different from the relevant AD(s): on the one hand, that can
improve efficiency because ADs are overworked.  On the other,
because that chair or those co-chairs are not nomcom-appointed
or subject to recall, there is less direct accountability to the
community and more ability for the IESG (or a particular AD) to
throw the co-chairs under an approaching bus and therefore avoid
accountability (or course, we've never seen things like that
happen in other areas of the IETF/IAB's work).

best,
   john





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

  Powered by Linux