Re: [Diversity] Concerns about Singapore

[Stephen Farrell <[e-mail]>]

Dave,

I think you and I just disagree about the requirement for the IAOC
(not just f2f arrangements folks) to reform itself or be reformed.
That, or else I'm just not explaining myself at all well, presumably
leading you to your clearly dismissive reference to magical thinking.

In contrast, I think the current fiasco is just one in an ongoing
sequence of mostly minor screw-ups by well meaning folks, all or
almost all of which would likely have been easier to handle or
less likely to happen if the IAOC and it's subcommittees made much
better use of what is the IETF's standard modus operandi: open-ness.

And before you again mis-characterise me as implying that every
detail of every hotel contract be open, that is clearly not what I
am proposing. If you take that to be my proposal either the writer
or the reader or both are at significant fault.

S.

On 10/04/16 20:49, Dave Crocker wrote:
> Stephen,
> 
> 
>> (We're maybe wandering from the direct relevance to this list,
>> but I think many of the right people are subscribed to most of
>> the possible lists so let's continue...)
> 
> Actually, we're not.  There is a tendency to believe that diversity
> issues are solved by better awareness, or better documentation, or more
> diligent attention, or by enforcing well-intentioned-but-artificial
> membership quotas on committees.  None of those suffice for complex and
> emotional social concerns, of the sort we are currently seeing.
> 
> So discussion about the best ways to ensure on-going handling of such
> issues is entirely relevant.
> 
> 
>>> The IAOC (and the Meetings Committee that I participate in) means well
>>> and attempts to be diligent, but it simply is not certain (or IMO,
>>> likely) to adequately assess these kinds of community concerns well
>>> enough.  Last week demonstrated that.
>>
>> I do agree, both that folks are well meaning and that we're
>> almost certainly going to have future surprises and issues
>> to tackle no matter what we do.
> 
> What I am advocating -- and I'm not the one who put the idea forward --
> /does/ ensure no further surprises about basic venue legal,
> environmental, political or social acceptability.
> 
> 
>> But since I apparently was not clear enough before, here's another
>> attempt to say what, in addition to handling IETF-100 specifics,
>> I think the IAOC needs to do now:
>>
>> - Decide to, and announce, that the default position is to be open
>>    with all data, email etc. That should happen now. (Or should have
>>    happened already perhaps.)
>>
>> - Publicly describe the specific kinds of information that are not
>>    handled according to the default-open policy.
> 
> Stephen, that's an example of magical thinking about transparency.
> Sounds good but isn't practical for most administrative work or most
> administrative environments.  In ignores costs and inefficiencies and
> imposes unrealistic burdens on the folk doing the work.  (By the way, it
> also imposes unrealistic burdens on the community, who have to pay very
> close attention, all the time, to all this new detail being made
> available...)
> 
> Further, you are calling for massive operational changes, with only
> modest direct relationship to the problem at hand.  By contrast, the
> suggestion I'm advocating is simple, cheap, safe, and effective for
> exactly the kind of issue at hand.
> 
> 
>> Lastly, having seen the incremental increases in open-ness that the
>> IESG has made in the last 5 years, and that not one of those has had
>> a bad effect that I can recall, despite some fears each time we opened
>> up more, I think that while some IAOC folks might understandably
>> be a bit afraid of a default-open policy, I reckon doing so is likely
>> to just work, if done well.
> 
> I'm in favor of a great deal of openness.  And I concur that the IESG
> steps have been a Good Thing.  But IMO venue administrative work is
> quite different.
> 
> At the least, the politics of turning down a venue and/or a host
> involves far more delicacy than is possible with a fishbowl operational
> model.
> 
> d/
>