Re: [Manycouches] many-fine-dinners --- a view on how to organize virtual meetings

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 28 November 2020 08:13 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: manycouches@ietfa.amsl.com
Delivered-To: manycouches@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22B43A0E89 for <manycouches@ietfa.amsl.com>; Sat, 28 Nov 2020 00:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 WySf6wn7Wqia for <manycouches@ietfa.amsl.com>; Sat, 28 Nov 2020 00:13:01 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E270E3A0D2C for <manycouches@ietf.org>; Sat, 28 Nov 2020 00:13:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A209389F2; Sat, 28 Nov 2020 03:14:31 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Bu20tixVt1CD; Sat, 28 Nov 2020 03:14:30 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D712F389EF; Sat, 28 Nov 2020 03:14:30 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 47CB897F; Sat, 28 Nov 2020 03:12:58 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Martin Duke <martin.h.duke@gmail.com>, "manycouches@ietf.org" <manycouches@ietf.org>
In-Reply-To: <CAM4esxQdW2N=NAwgGpJKc3Q9xdyDRG1K-R=75vK7wi2tUO9btQ@mail.gmail.com>
References: <160288855079.14008.13967692974159638979@ietfa.amsl.com> <30344.1602894208@localhost> <FD995870-E9C6-4099-93AF-253F0A11F56B@tzi.org> <CADaq8jcKK5kUvU3v7+6gEaeqjqxtw-Bii5is_hoq1ugogCoWPg@mail.gmail.com> <20201017193610.GA39170@kduck.mit.edu> <12526.1602980594@localhost> <2f99a293-b2b1-498f-36af-36fd201e9e8d@joelhalpern.com> <15451.1603056956@localhost> <2a305ee7-7511-f74d-fd7b-93ff8641c451@joelhalpern.com> <17295.1603123341@localhost> <228dbe14-2362-7374-bf1c-768c6ada7a3f@joelhalpern.com> <5926.1603128427@localhost> <a11e38fd-7d21-112c-fbe9-dc4b699ca5fe@joelhalpern.com> <13688.1604619321@localhost> <E441A975-F3E0-4011-86E5-AAC7494EBE31@cisco.com> <CAM4esxQdW2N=NAwgGpJKc3Q9xdyDRG1K-R=75vK7wi2tUO9btQ@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 28 Nov 2020 03:12:58 -0500
Message-ID: <3976.1606551178@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/manycouches/NaRoRa744F7FRuosclitLR7WlFg>
Subject: Re: [Manycouches] many-fine-dinners --- a view on how to organize virtual meetings
X-BeenThere: manycouches@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List is a design team list to identify issues that would arise should an IETF meeting ever be held with O\(1000\) 'remote' participants." <manycouches.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manycouches>, <mailto:manycouches-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manycouches/>
List-Post: <mailto:manycouches@ietf.org>
List-Help: <mailto:manycouches-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manycouches>, <mailto:manycouches-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Nov 2020 08:13:04 -0000

Martin Duke <martin.h.duke@gmail.com> wrote:
    > 5. *More interim meetings*: the near-universal interim start time of ~1500
    > UTC makes a lot of inherently discriminatory assumptions about what time
    > zones have the most important contributors and what hours are optimal for
    > any particular time zone. If we were to have regular virtual IETFs without
    > a canceled location as a timebase, using a random start time would be
    > better than optimizing for the Atlantic. That said, sometimes WGs enter a
    > phase where they're in the weeds, tourists are not that helpful, and indeed
    > entirely theoretical anyway. For these groups, interims are currently
    > available but I don't think we should be in the business of actively
    > encouraging interims for the reasons above.

I kind of like the idea of a random start time.  Would it include time zones
in the middle of the Pacific?

But, I haven't seen the it be random yet, nor have I seen it actually
respect the timezone of the cancelled location.

Had we used a 9am start for IETF109, for instance, it would have been much
nicer to the Pacific coast people: the meeting would have been over before midnight.
Yes, it would have been crueler to Europeans, but the last two meetings have
been very nice to them, and being in the middle, they are most accomodated by
random start time.

If we can recognize that WGs are in the weeds then we can help them.
Having them meet during IETF week may be a thing that could help them.
(even if the time zone is inconvenient)
{Tourists that don't take up mic time are free}

I am concerned about ADs that might feel that they have to attend these
virtual interims.   Watching it on youtube at 2x speed is sometimes as good
as being there.

    > Furthermore, in many ways "have an 11am meeting every day for a month" is
    > more onerous than just blocking out a week. As the intended purpose of more
    > interims is to encourage more tourism in meeting week, this amounts to one
    > busy week followed by 1 month of daily meetings. I found this IETF 107
    > model to be far more disruptive than the alternatives.

I agree that the 11am meeting every day is a serious problem for many.

    > All this said, fewer conflicts are good! To me, the most promising avenue
    > is shortening sessions and placing restrictions on how many you can
    > request, a forcing function to reduce status reports and non-interactive
    > presentations, and instead focus on issues that require live-action
    > discussion. Of course, one of the big requests we got between 108 and 109
    > was "longer sessions", so your mileage may vary.

Maybe we should have standard tooling to allow participants rate each presentation.
It should include ability to say, "More time was needed", "it was a waste of time"
This is feedback to the chairs.

I have added the following text based upon your comments and those of Alissa
at the mic:

...

 2. frequent participant-time-zone optimized
 3. typically occur at twice-monthly to monthly intervals appropriate for getting work done.

There is a significant self-selection problem with virtual interims and participants.

In groups where the use of virtual interim meetings are used a lot, the
choice of time zone in which to hold the virtual interim meeting can
determine who attends.

When the virtual interim time zone selects against participants from a
particular part of the world then they tend to participant less.
If the working group then does a poll of participants as to what time zone to
use, then having lost participants from the less popular time zone, the
result is likely to reinforce this selection.

This suggests that virtual interim meeting time zones should not *always* be
chosen according to popularity (such as "doodle" poll).
But, at the same time, a working group which is highly focused and doing good
work should be forced to work at inconvenient times.

There is a definite tussle here!

The IESG is encouraged to find ways to insert some variation in meeting time.
This needs to be done with care, and with some amount of sharing of the pain
among different working groups as well.

#### 1500UTC

The 1500 Central European time (in whichever Daylight Savings is active),
corresponds to 7AM Pacific, 10AM Eastern, 2PM (UK), 3PM (Paris), 4PM
(Helsinki), and 10PM Beijing.

This time period is used for IESG Thursday meetings, and is popular because
it accomodating to many participants.

It is hostile to Eastern Australia, New Zealand and Hawaii participants.
Fundamentally, the lack of people who live in the Pacific ocean biases the
time zones to those which are daytime in Europe, which is essentially in the
middle.

It is therefore difficult to "share the pain" --- those at the extremes
(Pacific North America, and Asia/Pacific) will find the times picked to
almost always be annoying.

To be clear: while a meeting could be planned for early evening (16:00) in
San Jose, which is early morning in Tokyo (9AM), it would be outside of
office hours, or even night for most everyone else in the world.


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide