Internet DRAFT - draft-richardson-shmoo-how-many-fine-dinners
draft-richardson-shmoo-how-many-fine-dinners
shmoo Working Group M. Richardson
Internet-Draft Sandelman Software Works
Intended status: Best Current Practice 28 November 2020
Expires: 1 June 2021
How often and how long should IETF virtual meetings be?
draft-richardson-shmoo-how-many-fine-dinners-02
Abstract
This document recommends a model for IETF virtual meetings that
emphasizes new work, community building and cross-area concerns.
This document recommends virtual meetings be planned a reduced amount
of overlap among sessions, with short sessions with generous gaps.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 June 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Richardson Expires 1 June 2021 [Page 1]
Internet-Draft Dinners and Lunches November 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. IETF 107 experience . . . . . . . . . . . . . . . . . . . 2
1.2. IETF 108 experience . . . . . . . . . . . . . . . . . . . 3
1.3. IETF 109 experience . . . . . . . . . . . . . . . . . . . 4
2. Suggestions for future meetings . . . . . . . . . . . . . . . 5
2.1. Principles for for Recommendations . . . . . . . . . . . 5
2.2. Recommendations on meeting structure . . . . . . . . . . 6
2.2.1. Encourage Virtual Interim meetings for ongoing
work . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Allow IETF Virtual meeting week to focus on
community-wide activities . . . . . . . . . . . . . . 7
2.2.3. Number of Tracks for virtual meetings . . . . . . . . 8
3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Normative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
IETF107 (Vancouver) was the first pandemic IETF virtual meeting held
in March 2020. IETF108 (Madrid) was the second pandemic IETF virtual
meeting held in July 2020. IETF109 (Bangkok) was the third pandemic
IETF virtual meeting held in November 2020.
IETF110 (Prague), will be held as a virtual meeting in March 2021.
It is unknown at the time of this writing whether IETF111 (San
Francisco) will be possible.
1.1. IETF 107 experience
IETF107 consisted of a light week with no more than about 4-hours of
sessions over Monday to Thursday. There were multiple tracks
simultaneously, but not more three sessions at any one time.
Priority was given to newly formed WGs that had not yet met, to Birds
of a Feather session, and to cross-community sessions including
specifically "dispatch" sessions.
These sessions were done with XXXX (webex? right?)
The timezone was approximately "Vancouver"-ish. Most sessions
started in late morning, which turned into mid-evening in Europe
(going into midnight), and middle of the night in Asia.
Richardson Expires 1 June 2021 [Page 2]
Internet-Draft Dinners and Lunches November 2020
All other WGs were assigned a day in the weeks following IETF107 from
March 30 to April 30. The WGs were asked to pick a time (and time
zone) convenient to them, and they scheduled webex meetings on
"ietf.webex.com", although a few WG chairs decided to use "Zoom".
Many meetings occured in the North-America/Europe optimal time slot
of 1500UTC ("10am EDT").
Despite the "pick a time", a small number of WGs managed to pick
times when other WGs were meeting, and there were in fact collisions.
IETF 107 would be best described as a marathon rather than a sprint.
1.2. IETF 108 experience
IETF108 consisted of a very heavy week.
Eight simultaneous tracks were scheduled, although with slightly
shorter meeting times of 50 minutes and 100 minutes. The plenary
occured at the normal Wednesday afternoon time, and other constants
like "saag" being on Thurdsay afternoon were also maintained.
The day started in late-morning "Madrid" (Central Enropean) time and
ended before dinner time. The longest break was a 30 minute break
after the first session. Other breaks were in the 10 minute range.
This accomodated East-coast North-Americans, but Pacific coast
participants had to get up for 4am. The schedule accomodated those
in Asia slightly better, but it was still middle of the night in New-
Zealand for all but the first sessions.
All WG sessions used meetecho with additional features having been
added to support things like humming, and some slightly better queue
management.
Many participants experienced a typical number of conflicts. See,
for instance https://mailarchive.ietf.org/arch/msg/suit/
OcyNDcssHW8NUrCxGMzCJMX73_M/
Some WGs declined to schedule meetings at IETF108. This was due to a
combination of scheduling, timezones and the fee to attend. WGs that
did this usually had a healthy and regular set of virtual interim
meetings that were ongoing.
To some, IETF 108 felt like a sprint: others felt that the pace,
while intense was okay if one paced oneself well.
Richardson Expires 1 June 2021 [Page 3]
Internet-Draft Dinners and Lunches November 2020
1.3. IETF 109 experience
IETF109 consisted of a heavy week similiar to IETF108.
Eight simultaneous tracks were scheduled. Each day had a two hour
slot, a thirty minute break, a one hour slot, another 30 minute
break, and then a two hour slot.
Survey feedback said that participants perferred that the meeting
time be as compressed as possible, so the total meeting duration was
6 hours long.
The day started in afternoon "Bangkok" (UTC+7hours: 1pm) time and
ended before dinner time.
Participants on the West coast of North America (California,
Vancouver, Seattle, etc.) were 16 hours behind, so the meeting time
of 0600 UTC worked out to start at 2100 (PST) the night before, and
went until 0300 (PST). It was a late night for those participants.
Participants on the East coast of North America (Toronto, Boston,
NYC, Atlanta, etc.) were 13 hours behind, so the meeting time of 0600
UTC worked out to start at 0000 (EST) the night before, and went
until 0600 (EST). Participants either slept during the day (7am to
3pm) and then got up and spent the evening with their family, or they
slept during the afternoon/evening (3pm to 10pm), and got up and
joined "first thing". Those who slept during the day usually did so
because that's when their house was quiet (partner at work, children
at school): they did the meeting at the end of their day. Those who
slept in the evening, seemed to cite being able to collaborate with
European colleagues after the meeting, during the European "day"
Participants in Europe found the meeting start time of 0600UTC meant
that they had get up a bit early. (This experience was similiar to
the IETF108 experience for East Coast north Americans) They meeting
then occupied most of their day.
At the time of this writing, no feedback from Pacific/Asian
participants was received. Input is sought.
Side meetings were a challenge: a few had side meetings during the 30
minute breaks, but many people socialized on gather.town. This was
also used for one on one follow-up discussions. Getting more food,
drink, and attending to washroom needs were also important to most
participants.
Richardson Expires 1 June 2021 [Page 4]
Internet-Draft Dinners and Lunches November 2020
A few side meetings were called for after the meeting time, that is
after 1200UTC. This was convenient for Europeans and Asian
participants, and East Coast participants who slept in the evening,
but it did not work for West Coast participants at all.
IETF109 seemed much better attended than IETF108.
2. Suggestions for future meetings
2.1. Principles for for Recommendations
There is great utility in having all of the IETF members present and
available together. Doing this in-person has many great benefits
(and many costs internal and external), not enumerated here.
An unconstrained meeting with few conflicts and a few empty slots in
each individual schedule maximizes the benefit of the togetherness.
Some call it Working-Group "tourism", others call it "impromptu
cross-area review", but there are significant benefits to having
"bored" participants with time on their hands wander into a WG to
which they have little knowledge.
To be fair, there is some significant negative experience with mic
comments like, "I haven't read the document, but..."
Yes, often these comments _do_ lead to significant amounts of
friction. Time wasted at the mic explaining that that were covered
in the document.
Sometimes, though, they lead to an understanding that two WGs are
facing the same issues, and that they should work together. And
getting this understanding is really quite valuable.
This is _PARTICULARLY_ the case for new work (BOFs), and for the
first few meetings of a newly formed WG. One of the important thing
for many individuals to internalize what the boundaries of the new
work is, and what the overlap with the work they are doing is. This
often comes about from the discussions that go around slide ware, to
seeing who else cares about this work, and why.
Heavily conflicted (physical) meeting schedules have been a growing
issue, with the result that many people do not have the time (due to
conflicts), or the energy (due to exhaustion) to pay attention to the
new work.
Richardson Expires 1 June 2021 [Page 5]
Internet-Draft Dinners and Lunches November 2020
2.2. Recommendations on meeting structure
2.2.1. Encourage Virtual Interim meetings for ongoing work
This document therefore recommends that the IETF encourage a healthy
growth of virtual interim meetings which are:
1. heavily focused.
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.
2.2.1.1. 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.
Richardson Expires 1 June 2021 [Page 6]
Internet-Draft Dinners and Lunches November 2020
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.
2.2.2. Allow IETF Virtual meeting week to focus on community-wide
activities
While the IETF mission statement is very outcome focused, that
doesn't mean that every activity needs to be only outcome focused. I
think that the IETF "plenary" meeting times should be arranged to not
just permit, but encourage cross-working-group participation.
This document suggests that the IETF virtual meeting week be focused
on:
1. governance and meta-activites like IESG, IAB, NOMCOM
2. *DISPATCH activities
3. BOFs for new work
4. growing the virtual Hackathon
5. newly formed WG meetings,
6. maybe WGs who have gone through some major milestone, and are for
instance, rechartering
Rather than attempt to compress the schedule down so that the time
between the beginning of the day and the end of the day is as short
as possible, we should instead arrange the schedule with generous
break intervals to accomodate adhoc 1:1 or rather-small-group
meetings.
That is, the "hallway session" needs some time and space to be
useful.
In particular, having some gaps where a person can reasonably expect
to track down someone else to chat about a specific thing, or just to
catch up.
We used to stimulate the "hallway" discussion using cookies and
beverages.
Richardson Expires 1 June 2021 [Page 7]
Internet-Draft Dinners and Lunches November 2020
Often this is the best way to talk though DISCUSSes among ADs and
document authors.
Those that used the gather.town system, found it was exceptionally
useful for this.
2.2.3. Number of Tracks for virtual meetings
This document recommends that we have fewer tracks. Somewhere
between two and four.
That is, like IETF108 and more like IETF107. A few more tracks, and
slightly longer days.
This document does not recommend that the schedule be adjusted to
accomodate all the time zones. Because of where the Pacific Ocean
is, that pretty much always puts noon somewhere near Greenwich.
The 1-1-1-* process should mean that the locale chosen for the
cancelled physical meeting defines the time zone. Participants
should be expected to "travel" to that time zone: many physical trips
take 24 to 36 hours of airplane time, and asking participants to take
a similiar amount of time to adjust their body clocks is not
unreasonable.
Once a year, the participants will find they have to do almost no
adjustment, when the meeting is "near" them.
Meetings should be restricted to between a 4 and 7 day period though,
which gives them some time to adjust before "returning" to work the
next week.
Historical meetings have accomodated in excess of 200 hours of
session time. (Eight hours/day X 4.5 days X eight tracks = 288
hours, minus some for the plenary).
The virtual meeting should restrict itself to approximately 100 hours
of session time. 6 sessions of 50 minutes, with ~30 minute breaks
between, over 4 tracks, and over 4 days gives 90 hours of session
time. This calculation does not count time for a plenary where there
is only one track. This formula is intended to be a guideline only.
Note that for many, conflicts mean that they have to view the session
after the fact via Youtube. While the "play back at 2x speed" can be
effective for some listeners, this can result in significant number
of extra hours of time for the meeting.
Richardson Expires 1 June 2021 [Page 8]
Internet-Draft Dinners and Lunches November 2020
Rather than compete for available plenary-week WGs slots, WGs should
compete to demonstrate that they don't need a slot.
Having a plenary-week slot should mean that additional "supervision"
is required :-) Either because the WG is very new, or because the WG
is old and has lost it's way.
3. Security Considerations
The excessive use of caffeine and sugar to adjust jet lag may have
health effects on the participants. In addition, there is some
possibility that decisions made under such influence might negatively
affect the security of the Internet. Multiple reviews after periods
of "sober second thought" should catch any such poor decisions.
4. IANA Considerations
This document makes no requests to IANA.
5. Acknowledgements
YOUR NAME HERE.
6. Changelog
7. Normative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Author's Address
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
Richardson Expires 1 June 2021 [Page 9]
