Re: [Mtgvenue] issue #3: Too many mandatory

Dave Crocker <dhc@dcrocker.net> Wed, 05 April 2017 21:03 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: mtgvenue@ietfa.amsl.com
Delivered-To: mtgvenue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABD6129498 for <mtgvenue@ietfa.amsl.com>; Wed, 5 Apr 2017 14:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOlt6qMpjg4T for <mtgvenue@ietfa.amsl.com>; Wed, 5 Apr 2017 14:02:59 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48EB1270A0 for <mtgvenue@ietf.org>; Wed, 5 Apr 2017 14:02:59 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v35L588P021381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <mtgvenue@ietf.org>; Wed, 5 Apr 2017 14:05:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1491426308; bh=MKH4w3C+/zjj6/06B0IABdWaJ8H2yMP8f/Ic2MCdzxQ=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=OpOJtZNX9Gs/vZVuX1TaMzOniwslrwwXY9QJSwVOzveog7+vqu39/Ol3TTBqmGIGQ G5MQyYJ1PgE3ETdC0GOGqc/ehfQMk2ZOZbnuGpoJIoZGHjyYzopb0EXHhipHfEFrAN mC3GEU3TZg0xpJQ6/LisvE/V4GtPpKugaT5T1Wa4=
To: "mtgvenue@ietf.org" <mtgvenue@ietf.org>
References: <37de22dc-04a4-f868-698e-cf03cd791957@cisco.com> <7add7c4a-032f-6b78-5b5f-861835a64f9a@dcrocker.net> <006325a5-83e7-9295-71a1-67c0125aa7cb@cisco.com> <c57adf52-3db7-5cfc-d301-3135010e17c6@cs.tcd.ie> <CA+9kkMA7iQrMg2y6g5=i96HL3-_8X04BsQjZEhzWe++uZzJvmQ@mail.gmail.com> <86de8a9c-3de3-dc35-b4e3-42553b91a53a@dcrocker.net> <CA+9kkMDgwgHd0-THd_eENrCf0GfLjQaMSivx3phX5Bkgyb=fiA@mail.gmail.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Reply-To: dcrocker@bbiw.net
Message-ID: <b706e895-0e7c-8883-7188-9e1c6891780e@dcrocker.net>
Date: Wed, 05 Apr 2017 14:02:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <CA+9kkMDgwgHd0-THd_eENrCf0GfLjQaMSivx3phX5Bkgyb=fiA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/rW1o4YKcYTqWVe8x1Anb00r8Qdw>
Subject: Re: [Mtgvenue] issue #3: Too many mandatory
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for email discussion of the IAOC meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Apr 2017 21:03:02 -0000

>> Mandatory:  If not met, don't schedule the meeting here and move or cancel
>> the meeting if the requirement ceases to be met.
>>
> Mandatory:  Do not select this site for a meeting.  Move or cancel the 
> meeting if the requirement ceases to be met.
> 
>> Exception-required:  Confirm that these are met during scheduling or get
>> community confirmation of the exception.
>>
> Exception-required: Confirm that these are met while considering a site 
> for selection or get community confirmation of the exception.  If they 
> cease to be met and will not be met at the time scheduled for the 
> meeting, confirm the exception with the community.
> 
>> Important:  Things we care about but which can be traded off if the balance
>> of requirements is met without confirmation by the full community.
>>
> Important:  Things we care about when selecting site but which can be 
> traded off if the balance of requirements is met without confirmation by 
> the full community.  If these cease to be met after selection, these is 
> no need for community confirmation unless the balance of requirements is 
> no longer met.
> 
>> Desired:  Things we like, but which can be dropped without having an impact
>> on the meeting's effectiveness.
> 
> Desired:  Things we like in sites, but which do not have an impact on a 
> meetings effectiveness and thus can be considered in site selection 
> without being true requirements.
> 
>     All sorts of things happen after a venue is 'selected'.  These
>     things are quite distinct form 'selection'.
> 
>     Contracting is one of those steps.  Another is monitoring and
>     re-evaluating if conditions change.  Those are, of course, essential.
> 
> 
> The draft as currently constructed covers those as venue selection 
> steps, at least as I read Section 5.  If each of those steps needs a new 
> document, we may be here a while.


"move or cancel" is language that only has meaning /after/ selection. 
It is therefore formally out of scope.

And while I'm at it...

The effort to move to a yet-more complicated ranking system -- adding 
Exception into the mix -- is mostly continuing to ignore the human 
factors points I keep raising:  Both in creating such a ranking list and 
in applying them, free-form human performance mostly sucks.

On the creation side, people are inconsistent in their assessment, from 
one hour to the next, never mind one day to the next.  On the 
application side -- absent quite a lot of on-going training and quite a 
lot of diligent application -- people are quite horrible at 
decision-making that properly juggles such a range of nuanced requirements.

So as folk comfortably move towards these changes, please do explain how 
they will be used in practice and what the basis is for believing that 
it will be practical for the Meetings Committee and for the staff.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net