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

Martin Duke <martin.h.duke@gmail.com> Thu, 19 November 2020 23:49 UTC

Return-Path: <martin.h.duke@gmail.com>
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 3799F3A13D5 for <manycouches@ietfa.amsl.com>; Thu, 19 Nov 2020 15:49:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 c-Qdd0ooLR5a for <manycouches@ietfa.amsl.com>; Thu, 19 Nov 2020 15:49:15 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 330543A140B for <manycouches@ietf.org>; Thu, 19 Nov 2020 15:48:22 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id r1so8029929iob.13 for <manycouches@ietf.org>; Thu, 19 Nov 2020 15:48:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6fsYddB6n79Ka8h1DcNMEHTyjRns2HL/5P3Wh/yAf9I=; b=cTmgxEx4i7aBR/+7Ll8P5Jg7HemT7YO2GBRVPXhsIx1TZmSVVA40/OMGWiYxxyeQnw m8d0/C3HWMTVkowAQgZfzjQX73SG04JwSNtyQYnj7MrUt5s37bGGvxD4nMNQV6fAfe8R OWA6SVOTPBFITRwXuLy3As0ILLUurSHwfPARDqR2MPouKPn6zQGlJpRZQM/6OlphmlrZ Xbmm+xkWbrtgSVCOMYYRJ7dE6u+Tcn1o1JV5LOXnxm94Uqsb9Tu9mauWE6jvnMJrgnxQ ig/zJHDpEjshkI34xMeuQ3VT4srlm4djP+UjcK2qThqgciaNy2rBbEcqBXPnP1nzvUb6 I1JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6fsYddB6n79Ka8h1DcNMEHTyjRns2HL/5P3Wh/yAf9I=; b=g51zRxmk/NOC/kZT7Hi/IwxKqigCvOwft7uIHTxGcNLYEGskE1FeP2yJlNQrGwLG7g fXZ+hmYhbISw2CNnUwkuvkbUv2tqLp/M9JxrIlLidPG5WalgOt+VOwUJ191Ryotf4y4L jWZUVtae93schdyFWXy7mf+Jeengewwna0Tyr+gJROlFMfipfW8pNHElK0H0MIyGXV8P tOS8iF9w1JsUKVs4dabNAp0ehkMY0Se1G+Cc88A14P1gyxOnBWyZwN5zb2j3eJPGlUHY fNqSO2VWn5unwfrdoFt816Y4fKA3W3iu6CgKlMx1EQcKN2LEwa2Sqa22Z8lCD2YbxEUs BR1A==
X-Gm-Message-State: AOAM530ZDg85//KuzJjdYDoCXo6hFHu9EE0H4zzwBB6nab6/foDtN4NU Zpo0W6WhkuHp4c3TyYv0NFz6irA6GxivqYvu7Ozk7f5JQyo=
X-Google-Smtp-Source: ABdhPJyGuFIShysQuR4ZYWplgsTSf9+KKXBZt6R+5+dYNXst6mO4G1hyNR6DAemRBRSerD1jMQqInaooK3Bod6JxSH4=
X-Received: by 2002:a5d:9a03:: with SMTP id s3mr9772557iol.20.1605829701319; Thu, 19 Nov 2020 15:48:21 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <E441A975-F3E0-4011-86E5-AAC7494EBE31@cisco.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 19 Nov 2020 15:48:22 -0800
Message-ID: <CAM4esxQdW2N=NAwgGpJKc3Q9xdyDRG1K-R=75vK7wi2tUO9btQ@mail.gmail.com>
To: "Charles Eckel (eckelcu)" <eckelcu=40cisco.com@dmarc.ietf.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "manycouches@ietf.org" <manycouches@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary="000000000000eabe9405b47e5cbc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/manycouches/PyCYTETPTCseWuyVhZ_Vnexp0IE>
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: Thu, 19 Nov 2020 23:49:18 -0000

Michael,

I read this draft and started formulating a comment to deliver at the mic,
but it got out of hand, so I'll put it in an email instead.

1. I support a draft on this topic but found myself disagreeing with the
conclusions as I understand them. Full disclosure: I am part of the IESG
committee that created the current approach and am therefore more
responsible for the current format than others might be.

2. I take the central thesis to be that there are too many conflicts
because there are too many parallel tracks, and that we should take several
measures to reduce the number of tracks, which would also increase
socializing time in gather.town or whatever. A few thoughts on "too many
conflicts":
(a) The number of tracks (8) is consistent with past in-person meetings,
although of course we're not constrained by that.
(b) The IETF 108 survey results (which I cannot find a public link to)
showed about a 4-1 preference for the IETF 108 format to the 107 format
(which I understand you as advocating a partial return to).
(c) I will assert without evidence that the majority of participants don't
have so many WG interests that they are confronted with widespread
conflicts, and have sessions where they can have side meetings and
unscheduled time in gather. We should actually collect data on this, though!

As to your specific recommendations:
3. *Longer days*: The IESG's consensus is that more than 6 hours of
videoconferencing is tough on the body under any circumstances, especially
when it's the graveyard shift for many people.  Furthermore, I believe that
people have a harder time filtering out their everyday life constraints
when at home, and so a longer day is particularly onerous.

4. *More days*: This would increase the true cost to employers, compared to
an in-person meeting, if it were any more than about 7 working days. I
believe, without any evidence, that holding sessions over the weekend would
be a non-starter for participation.

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.

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.

**********

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.

Martin

On Thu, Nov 19, 2020 at 3:16 PM Charles Eckel (eckelcu) <eckelcu=
40cisco.com@dmarc.ietf.org> wrote:

> Hi Michael,
>
> Nice draft covering many important topics. Thanks for writing it.
>
> On 11/5/20, 3:35 PM, "Manycouches on behalf of Michael Richardson" <
> manycouches-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:
>
>
>     I posted draft-richardson-shmoo-how-many-fine-dinners-01 a few weeks
> ago, and
>     had a conversation with Joel Halpern.  He identified that something
> "seems
>     wrong" to him, and I had hoped that the -01 diffs would help him track
> down
>     the "smell".
>
>     He sent these notes, and agreed to let me share them:
>
>     Joel M. Halpern <jmh@joelhalpern.com> wrote:
>         Joel> I have read the today's version.
>
>         Joel> The following is a bit disconnected, but maybe from ehre we
> can figure out
>         Joel> how to get to a place we are both comfortable with.
>
>         Joel> The goal, as stated in the abstract, makes good sense to
> me.  I think that
>         Joel> the fact that I agree with this is why I was confused when I
> became
>         Joel> uncomfortable with the text later on.
>
>         Joel> I found the review of the last two meetings distracting and
> unhelpful. I
>         Joel> think it invites argument that is irrelevant.  The one
> reference later in the
>         Joel> document to it strikes me as largely unnecessary.
>
>     I understand.  I could move that to the end, but it felt like my
>     recommendations wouldn't make sense without understanding where we've
> been.
>
> I found them very useful. You could move them to a running list near the
> end or even in an appendix, but I fear this will lead to repeating a lot of
> important information. The current format worked for me.
>
>         Joel> I think that the last sentence of 2.1 is actually
> counter-factual.  I do not
>         Joel> see how the meeting conflicts have been a growing issue?  We
> have, as far as
>         Joel> I can tell, been getting better at managing the conflicts
> and scheduling the
>         Joel> sessions.
>
>     My experience is that conflicts are up, because we can now schedule
> many more
>     sessions efficiently.  We are just doing more work and having more
> WGs, but
>     really the number of active people is not increasing that much.
>
>         Joel> 2.2.1 is a place where I have a problem.  I work actively in
> a fair
>         Joel> number of
>
>     [2.2.1 Encourage Virtual Interim meetings for ongoing work]
>
>         Joel> working groups (as do you) plus external SDOs.  And I follow
> quite a few
>         Joel> others.  Plus the process stuff.  If most working groups had
> bi-weekly calls
>         Joel> it would be a pain.  If many of them had the calls in the US
> / Europe prime
>         Joel> slot (which Asia can often make), it would be a disaster.
> If it recommended
>         Joel> monthly, I probably would not argue.  If it recommended
> monthly for topics
>         Joel> that are receiving good email discussion and need more
> engagement, I could
>         Joel> not object.
>
>     I did say, "twice-month" (because I never know what bi-monthly is) to
>     monthly.  I agree that too many meetings is a problem, but then, being
> unable
>     to attend WG meetings during IETF week due to conflicts is also a
> problem.
>
> I think virtual interims are underutilized. Perhaps the formality of
> scheduling them is the culprit?
>
>         Joel> Which relates to something I have been trying for in the WGs
> I co-chair. If
>         Joel> someone wants an interim to discuss some topic, I push for
> email engagement
>         Joel> first.  If we do not see discussion on the list, why should
> we expect useful
>         Joel> discussion at an interim?
>
>     The experience of a few people is that it increases the connection
> within the
>     group, and effectively creates new deadlines.
>
>         Joel> We then get to the meet[meat] of the document, the bulleted
> lsit in section 2.2.2.
>         Joel> I think this misses a lot of the cases when
> cross-fertilization is at least
>         Joel> useful and maybe necessary.  Now topics become active
> without any milestone
>         Joel> being achieved.  Topics become "of interest" to the broader
> community at
>         Joel> times that have nothing to do with the milestones.  So I
> find the
>         Joel> recommendation that established WGs should not use IETF
> session time except
>         Joel> maybe at milestones to miss most of the important cases I
> have seen.
>
>     Well, I wasn't trying to restrict it to milestones, but rather give an
>     example of when it would be important to meet.
>
>         Joel> Which relates to my feeling that 2 parallel tracks is simply
> not
>         Joel> enough. Maybe we could make 4 - 6 work.  But 2?  No way it
> is sufficient.
>
>     Fair enough, the document says "two to four"
>     I see 6 as the same as 8: too many.
>
>         Joel> A tangentially related question is if we hold some meetings
> face-to-face and
>         Joel> some virtual, then maybe the virtual ones could be more
> lightly scheduled.
>         Joel> But that is a much more complex hypothesis.
>
>         Joel> I hope the above at least sheds light on where we can have
> fruitful
>         Joel> discussion of differences of opinion.
>
> Some additional comments,
>
> Section 1.2, "IETF 108 would be best described as a sprint."
> I would classify IETF 108, and IETF 109, more like a typical IETF meeting
> attended remotely, which is not a sprint in my mind. You needed to pace
> yourself for the week, so more like a 10K :)
>
> Section 2.1, "Heavily conflicted (physical) meeting schedules have been a
> growing issue ..."
>
> This depends on the type of attendee as well. If focused on a few WGs
> only, a more comressed agenda is better. For people who like to dive into
> everything, as is thankfully common with many long time IETFs, the packed
> agenda results in conflicts and difficulty checking out new things.
>
> Section 2.2.2, "This document suggests that the IETF virtual meeting week
> be focused on:
>
> I would add the hackathon and put it somewhere in the middle. One concern
> is that if many WGs are not meeting, fewer people will want to attend the
> in-person meeting and others will have a harder time to justify it. This
> would also hurt the Hackathon as the Hackathon alone may not be enough to
> justify a trip.
>
> Section 2.2.2, "Rather than attempt to compress the schedule ..."
> For me, the agenda for IETF 106 worked very well. The side meeting/free
> timeslot that was added plus breakfast, lunch, and dinner/post dinner were
> great and sufficient for this, including side meetings/BAR-BOFs, Hackdemo,
> etc. some of those evenings. Improved stay-for-lunch options would save a
> great deal of time and help facilitate as well.
>
> Cheers,
> Charles
>
>     --
>     Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
> consulting )
>                Sandelman Software Works Inc, Ottawa and Worldwide
>
> _______________________________________________
> Manycouches mailing list
> Manycouches@ietf.org
> https://www.ietf.org/mailman/listinfo/manycouches
>