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

Warren Kumari <warren@kumari.net> Wed, 05 April 2017 21:19 UTC

Return-Path: <warren@kumari.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 0CB55128B88 for <mtgvenue@ietfa.amsl.com>; Wed, 5 Apr 2017 14:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 9mvkxg2Uw-Bd for <mtgvenue@ietfa.amsl.com>; Wed, 5 Apr 2017 14:18:57 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAE8127A90 for <mtgvenue@ietf.org>; Wed, 5 Apr 2017 14:18:56 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id r45so21976342qte.3 for <mtgvenue@ietf.org>; Wed, 05 Apr 2017 14:18:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZAYRp4B5mhoiPuizbgkYCncH9Rv4/7Nq9WNOa4slbnw=; b=LSsijAemJoyQ2KXyP0I7G+8hs9I0Qphjd+TOWHAG44/TOk6wg+KEMEESzSql5iY06/ 0joFfcaSE7seigN4E9L+pIbicVTF3VcjXMF6RMIWfZ5fNsOWUdVMHxqO1Fu8P2OVjeox QgmE67NwaaE+ZQZJUVjEtsr8f7kbPH7vza8fgHj44DW+Cj+aSzQN8Z3FuFc9HgJoNRvm QRxAueFt/EqLmO3yCfBQsUceHRQV4CGR/FtWnmYEhUYLAEXAt1NsHSuJiXHVVMtUnXjB Wqy0V5l40iLQwd6VplI+RyVrgLjUIxqT61YLMYPUTBF3UWxGHYjF9MHO4B/dOBzruh/0 coTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZAYRp4B5mhoiPuizbgkYCncH9Rv4/7Nq9WNOa4slbnw=; b=C9x+bH/SVRff0Kl/LcWKatZFYGHJP24VjLic4X2+WjX0ORPNcE6qbhL1vttA0XUeIZ RtuoQCVGTLBLyHq4g+HX0iUIzvQGnvsdB4ufZm1K2QfxtZLD3yL8dZLDtyDUzvtyb0/V f5PKcuyro4fLruyIBKWKPiKdSjitRmskw0xfAAyqwIA2HYGZrMfEjB8yfmnDFFxts0EM P4kVhEPTiL6SWY1vO4lvDLwB4pdL8TH/SJqK79udgYIPSDUqiWTAu/ecfGVxQkTK01// xRZlFzDN3Q9DtG4qhYr//NGn8gTtkCHrMDrwTI6jpPdFKsJVLohBZHCXF3CKPxn2w5Mb vklA==
X-Gm-Message-State: AFeK/H2dZ7NsNikbZegS3uMJveBckVzK5yIhjUdxqn3LJLrUzQbCrR1vwCwIgnUlAdsDvUKRiqdQXnvX10iWvhbB
X-Received: by 10.200.48.174 with SMTP id v43mr31470794qta.263.1491427135789; Wed, 05 Apr 2017 14:18:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.177.11 with HTTP; Wed, 5 Apr 2017 14:18:15 -0700 (PDT)
In-Reply-To: <20170405201813.GF3439@mx4.yitter.info>
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> <20170405201813.GF3439@mx4.yitter.info>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 05 Apr 2017 17:18:15 -0400
Message-ID: <CAHw9_iLp_AbWRK7K+BHU5XuN3kYTsa3hazxRkhpOr2WFpm+PDw@mail.gmail.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: mtgvenue@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/JE-CQ0V3ClLmtMlas3MA7zgF4-M>
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:19:00 -0000

On Wed, Apr 5, 2017 at 4:18 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> Dear colleagues,
>
> On Wed, Apr 05, 2017 at 01:12:14PM -0700, Ted Hardie wrote:
>> I personally hope that the categories end up somewhere along the lines:
>>
>> Mandatory:  If not met, don't schedule the meeting here and 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.
>>
>> Important:  Things we care about but which can be traded off if the balance
>> of requirements is met without confirmation by the full community.
>>
>> Desired:  Things we like, but which can be dropped without having an impact
>> on the meeting's effectiveness.
>
> I quite like this set of requirements.  I do think there is utility in
> maintaining a category of Mandatory that means exactly what the drafts
> have said: if it can't be satisfied, then no meeting there.

... and this concern me. We select people to serve (presumably)
because we think that they have a brain, and are not intentionally out
to make the meetings fail.

I think that us creating strong rules like: "If X, then no meeting can
be held here" without letting those same people apply some judgement
and / or an exception process.

For example, I could easily see us writing:
Mandatory: Location must be at least 50KM away from a war zone, or a
border between 2 countries who are at war with each other.

This sounds like grand mandatory requirement; I know that I find it
distracting to have my presentation interrupted by an RPG passing
through the window, it distracts participants and makes hums difficult
to hear.

This would have ruled out Seoul - the DMZ is ~35km away, and, although
there is an armistice, (I believe) that N and S Korea are still
technically at war.
Dunno about you, but I liked Seoul, and felt safe...


>
> In addition, I agree strongly with Ted's suggestion about crisp
> "marching orders" for Madatory.  I think of the canonical case for
> Mandatory is "enough meeting rooms".  If there aren't enough, we're
> not going to have the meeting there, period.

This also sounds like a fine mandatory rule...

However, at a recent meeting (I *think* it was in Berlin, but cannot
swear to that) there were not enough "meeting rooms", and one of the
larger rooms was split into two smaller spaces with air walls.
Worked just fine. If we write Mandatory rules (with no exception
processing) we'll have to be very very precise as to what exactly we
mean - luckily we have many armchair lawyers we can rope in...
Personally I think it is preferable to explain what we really really
want (call it mandatory if we like), what we really want (important),
and what we'd like to have (desirable), and assume that the folk
running the process are a: mostly sane and b: not out to make us sad.

>
> This is why I don't like things like "Mandatory" for stuff like
> "travel costs are acceptable".  I don't know how to operationalize
> "acceptable" such that it is meaningful.

... and the fact that we have meeting selection *people* (and not
mindless machines) is why I don't like mandatory to be such an
absolute -- I think that we should always allow an out / exception
handling for corner cases...
So, I think that Mandatory should really mean "Do X, unless there is a
really good reason not to" -- this seems to be very very similar to
"Exception-required", and so these should just a a single level.

I also think that it is impolite to assume that we need to document
things like: "Thou shalt not meet in a location if there is not enough
space". If we really think that the folk selecting meeting venues
cannot figure that out, then we have bigger issues, and no amount of
documentation will solve it...

W
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
>
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf