Skip to main content

How often and how long should IETF virtual meetings be
draft-richardson-shmoo-how-many-fine-dinners-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Michael Richardson
Last updated 2020-10-12
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-richardson-shmoo-how-many-fine-dinners-00
shmoo Working Group                                        M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Best Current Practice                   12 October 2020
Expires: 15 April 2021

         How often and how long should IETF virtual meetings be
            draft-richardson-shmoo-how-many-fine-dinners-00

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 15 April 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 15 April 2021                 [Page 1]
Internet-Draft             MASA Considerations              October 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  IETF 107 experience . . . . . . . . . . . . . . . . . . .   2
     1.2.  IETF 108 experience . . . . . . . . . . . . . . . . . . .   3
   2.  Suggestions for future meetings . . . . . . . . . . . . . . .   3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   IETF107 was the first pandemic IETF virtual meeting held in March
   2020.  IETF108 was the second pandemic IETF virtual meeting held in
   July 2020.

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.

   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.

Richardson                Expires 15 April 2021                 [Page 2]
Internet-Draft             MASA Considerations              October 2020

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.

   IETF 108 would be best described as a sprint.

2.  Suggestions for future meetings

   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..."

Richardson                Expires 15 April 2021                 [Page 3]
Internet-Draft             MASA Considerations              October 2020

   Yet, often these comments _do_ lead to significant issues.

   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.

   This is also why heavily conflicted (physical) meeting schedules have
   been a growing issue.

   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.

   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.  meta-activites like IESG, IAB, NOMCOM

   2.  *DISPATCH activities

   3.  BOFs

   4.  new WG meetings,

   5.  maybe WGs who have gone through some major milestone, and are
       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.

Richardson                Expires 15 April 2021                 [Page 4]
Internet-Draft             MASA Considerations              October 2020

   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.

   This is to simulate the "hallway" discussion over cookies.  Often
   this is the best way to talk though DISCUSSes among ADs and document
   authors.  The gather.town was exceptionally useful for this.

   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 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).

   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.

   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.

Richardson                Expires 15 April 2021                 [Page 5]
Internet-Draft             MASA Considerations              October 2020

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 are always
   better.

4.  IANA Considerations

   This document makes no requests to IANA.

5.  Acknowledgements

   Hello.

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 15 April 2021                 [Page 6]