It's because, when you)re attending a virtual meeting that starts 2am your time, you're dead by 6am. I'm going with your first reason. No-one seems to really have recognised that virtual meetings can easily be staggered over several weeks, with a couple of meeting hours per day. But eventually, the realisation will be made that meetings that don't have to be compressed into physical space in a venue also don't have to be compressed in physical time, that lessened impact on schedules is worth it, and we'll commit to continuous partial attention. And when that happens, IETF Month will be established as a thing. three months a year. Lloyd Wood lloyd.wood@xxxxxxxxxxx is still not impressed with being called racist by draft-knodel-terminology-06 > On 3 Sep 2021, at 05:37, Adrian Farrel <adrian@xxxxxxxxxxxx> wrote: > > Thanks for thinking about creative ways to address these problems. > > Without commenting specifically about the experiment, I wonder whether you could clarify one thing for me. > >> fully online meetings have a shorter length of day > > Why is that? > Is it an attempt to minimise the out-of-comfort timing window? > Is it because people who are not travelling also have to fit other work into their day? > Is it because "that is what we have always done"? > > Thanks, > Adrian > > -----Original Message----- > From: IETF-Announce <ietf-announce-bounces@xxxxxxxx> On Behalf Of IETF Chair > Sent: 02 September 2021 17:41 > To: IETF-Announce <ietf-announce@xxxxxxxx> > Cc: wgchairs@xxxxxxxx; 112all@xxxxxxxx; IETF <ietf@xxxxxxxx> > Subject: Proposed Experiment for IETF 112: Moving the Plenary > > Hi, > > fully online meetings have a shorter length of day, which complicates > scheduling sessions to minimize conflicts, compared to an in-person > meeting with longer meeting days. The lack of travel arrangements also > reduces the pressure to hold all events in a single week. However, > scheduling all events in a single week both reduces the impact on > attendees' schedules and encourages cross-review of ideas. Past survey > data suggest both broad satisfaction with the current format and > concern about the number of scheduling conflicts. > > The plenary offers a unique opportunity to maximize benefits and > minimize costs. This single event consumes an entire 2-3 hour slot of > the meeting week across all tracks. Moving the plenary outside the > meeting week thus opens up eight long slots that can be used to > schedule other meetings. The experiment will test the hypothesis that > the plenary is compelling enough to draw attendees independently of the > rest of the meeting. > > *** Proposal > > For IETF 112, the plenary will occur on the Wednesday before the meeting > week (3 November 2021), in the time slot of 13:30-15:00 UTC, or > 14:30-16:00 Madrid time. At notable extremes, this begins at 05:30 in > San Francisco and ends at 02:00 in Sydney, with some of the less > popular hours over the Pacific. > > *** Feedback > > The IESG invites feedback to the IESG mailing list > (iesg@xxxxxxxx), especially if this proposal would change your ability > to attend the plenary. Such feedback would be most useful if received > within two weeks of the date of this email, as the IESG will then > finalize the decision whether to proceed with the experiment. Strong > feedback indicating the experiment would reduce the community’s ability > to attend the plenary might cause its cancellation. > > *** Success Criteria > > The IESG will evaluate the success of this experiment based on the > following criteria after its conclusion, in consultation with the > community. > > * An improvement in survey responses reporting session conflicts > compared to previous IETF online meetings > > * Positive response to a new survey question about subjective > satisfaction with the format change > > * Elimination of a ninth track, and a reduction in formal conflicts in > the final agenda compared to previous online meetings > > * Little or no reduction in plenary attendance (< 15%) compared to other > online plenaries in European time zones (i.e., IETF 108 and 110) > > * The subjective experience of the IESG and Secretariat in attempting to > minimize conflicts during IETF 112 > > This does not imply that all of these metrics must show > improvement for the experiment to be considered a success, or that > regression in any of them would indicate failure. The relative weights > of these considerations are a subject for IESG discussion and community > consultation. > > Lars Eggert > IETF Chair, on behalf of the IESG > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce >
