Move meetings times to 12,16,21

[ChALkeR]

Current ones are 14,17,22 — those seem to be far from being optimal (according to the meeting time options spreadsheet), and for two people that brings estimated participation levels below 30% (one of which — below 20%).

Switching to 12,16,21 essentialy means to:

1. Revert Moving 12:00 UTC time to 14:00 UTC #510,
2. Move the remaining two by one hour (probably mostly caused by daylight saving adjustment?).

Data from the tool:

• Expected participation levels for 14,17,22: average: 69.0%, stdev: .201, [current]
  row: 93% 93% 93% 88% 88% 79% 78% 74% 69% 69% 64% 64% 62% 62% 62% 62% 26% 18%
• Expected participation levels for 12,16,21: average: 72.3%, stdev: .149, [proposed]
  row: 91% 91% 87% 87% 87% 87% 78% 78% 78% 77% 66% 64% 64% 60% 59% 56% 49% 41%
• Expected participation levels for 12,16,22: average: 65.3%, stdev: .122,
  row: 89% 85% 81% 76% 76% 76% 71% 66% 62% 62% 58% 57% 57% 56% 56% 53% 50% 47%
• Expected participation levels for 12,21: average: 68.7%, stdev: .163,
  row: 90% 90% 90% 83% 83% 83% 83% 76% 70% 70% 70% 61% 52% 48% 48% 48% 48% 44%
• Expected participation levels for 16,21,21: average: 80.7%, stdev: .219,
  row: 95% 95% 95% 95% 95% 95% 95% 95% 94% 94% 90% 85% 80% 80% 63% 45% 34% 28%

Each value in a «row» stands for expected participation level of one person, rows are anonymized and sorted from most included (high percentage) to most excluded (low percentage).

Upd: exact predicted participation levels (non-anonymized) are available on the second sheet of the private document.

12,16,22 works a bit better for minimizing the stdev and bringing everyone as close to 50% participation plank as possible, but that lowers the average expected participation by about 4% instead of increasing it (as 12,16,21 does), which means about 1¼ persons less on a random meeting in average.

/cc @Trott, @fhinkel, @nodejs/tsc

Note: data is based on the current values in the table, updated at 2018-07-18 06:30 UTC.
I will update this in case if anything changes in the data.

[mcollina]

I’m definitely +1 with the move. The 22 time slot is impossible for me with daylight savings.

Side note, I think we should always reassess the timeslots after daylight savings changes have settled.

[ChALkeR]

@mcollina I plan to ad TZ support to the tool that I use to select those before the next DST shift, that should make things easier to track without everyone having to update the table in UTC all over after a DST shift (which is where we were blocked last time).

[ChALkeR]

Data updated, recommendation switched to just 12,16,21 again as 17 became not optimal.

[joyeecheung]

+1 to 12,16,21

[mcollina]

Definitely +1 to 12, 16 and 21.

[targos]

+1 from me too but I'd like to have feedback from people for whom those times are the worse.

[ChALkeR]

About the 14 timeslot — it does not look to be a part of any optimal set.

In fact, if the 12 timeslot could be moved somewhere — moving it to another 21 instead of 14 produces better results than moving it to 14:

• Expected participation levels for 16,21,21: average: 80.7%, stdev: .219,
  row: 95% 95% 95% 95% 95% 95% 95% 95% 94% 94% 90% 85% 80% 80% 63% 45% 34% 28%
• Expected participation levels for 14,16,21: average: 77.2%, stdev: .235,
  row: 95% 95% 95% 95% 95% 95% 94% 94% 90% 90% 80% 80% 70% 64% 64% 49% 28% 18%

I would suggest to keep the 12 timeslot though, as it does a better job for some people.

[mhdawson]

I'm good with any of the new options.

[ofrobots]

I'm also good with any of the options. In practical terms, my ability to attend will not be affected.

[Trott]

+1 from me.

[Trott]

(Thanks for doing the analysis, @ChALkeR. This stuff can be mind-bending.)

[fhinkel]

+1 from me but somebody would need to chair the 12 timeslot.

[mhdawson]

@nodejs/tsc I think we should agree on this in the meeting this week, so please chime in if you have any objections or other suggestions.

[mhdawson]

Agreed in TSC meeting to move.

Updated calendar, closing.