Update meeting times

[mhdawson]

• We need everybody to update their times in the spreadsheet (pinned in slack channel)
• Update to remove those who are no longer voting members
• Assess results and choose new times

I suggest we set the deadline to be Nov 17 for people to do their updates to the spreadsheet and we plan to propose/choose updated times the following week.

I think we'll need a volunteer to do the assess/proposal this time as @Trott is no longer a voting member. @nodejs/tsc any volunteers?

[Trott]

Because meeting attendance is no longer a factor in maintaining one's TSC voting membership, it might be worth considering a different approach to scheduling meetings. It is no longer essential that the meeting times work for everyone, even people who don't want to attend any meetings. The subset of folks who want to attend most or all meetings might be easier to accommodate, and it might be possible to do it with only one or two meeting times instead of the three or four that we typically use.

That said, if you want to keep doing it the way we've done it, I can certainly run the program as long as there is up-to-date data on people's availability.

[mhdawson]

@Trott can you run the program based on the current data. I think we've given TSC members enough time to update if they are going to. From that data we'll then propose new times.

[mhdawson]

Figured out how to run tool (https://github.com/nodejs/meeting-picker), proposal based on data:

Proposal

Based on the data my suggestion is that we pick

13,16,21 UTC unless there is a preference for 9 expressed over 13 as the first time by TSC members in this issue.

Unless there are suggestions to switch to 9 instead of 13 or other concerns/objections raised I'll update the meeting times after the next meeting (which is currently scheduled for 13 UTC anyway)

Data

TLDR

Data suggests
{ times: [ 9, 16, 21 ], standardDeviation: 0.3654742515847438 }
{ times: [ 13, 16, 21 ], standardDeviation: 0.37580073240507456 }

as top two on Wednesday. Data is incomplete for Thursday so I suggest we ignore for this cycle

More complete data

Wed (This is the same if I remove people who have not updated spreadsheet since 2022)
{ times: [ 9, 16, 21 ], standardDeviation: 0.3654742515847438 }
{ times: [ 13, 16, 21 ], standardDeviation: 0.37580073240507456 }
{ times: [ 8, 16, 21 ], standardDeviation: 0.3766866829911261 }
{ times: [ 13, 15, 21 ], standardDeviation: 0.37731823123067826 }
{ times: [ 9, 14, 21 ], standardDeviation: 0.3906039280030713 }

Thurs
{ times: [ 13, 15, 21 ], standardDeviation: 0.4146785903966267 }
{ times: [ 10, 15, 21 ], standardDeviation: 0.41987101193898424 }
{ times: [ 10, 14, 21 ], standardDeviation: 0.4298134285167615 }
{ times: [ 13, 14, 21 ], standardDeviation: 0.4308784631424504 }
{ times: [ 9, 15, 21 ], standardDeviation: 0.43166344915145793 }

The data is incomplete for Thursday with a number of people have blank lines.

[mhdawson]

@nodejs/tsc please review previous comment.

[Trott]

@Trott can you run the program based on the current data. I think we've given TSC members enough time to update if they are going to. From that data we'll then propose new times.

Sorry, I was going to get to this right now, but it looks like you beat me to it. Let me know if I can answer any questions or do anything for you. I would strongly recommend omitting data from anyone that hasn't updated their "Valid as of" column in the last few weeks.

[mhdawson]

@Trott thanks for the suggestions.

[GeoffreyBooth]

I updated the Google sheet to include Rich’s script directly in the sheet; and per Rich’s suggestions I removed Thursday and excluded from consideration the people who haven’t updated their times within the last 120 days. It yields this:

Times: Wednesday (UTC)	Standard Deviation
14, 15, 16	0.437

Do we need/want three separate times when they’re all so close? Perhaps we can just do two or even one?

[Trott]

Do we need/want three separate times when they’re all so close? Perhaps we can just do two or even one?

I think you can reduce the suggestions to 2 pretty safely, or maybe even 1. That used to be a CLI option in the tool, but I imagine now it will involve changing the code in the spreadsheet. You may also want to remove the fairness/standard-deviation stuff and instead go with: Pick the time that is best for the most people. Now grab all the people for whom that time doesn't work well, and pick the time that is best for that group. Done. Those are your times.

The meeting-picker was put in place to address fairness when attendance played a part in keeping one's TSC seat. Since that is no longer the case, making sure that everyone can reasonably attend 2/3 of the meetings is no longer a priority. Instead, it could just be: Make sure there is at least one time everyone can reasonably attend, and keep the number of meeting times to as small a number as possible.

[GeoffreyBooth]

You may also want to remove the fairness/standard-deviation stuff and instead go with: Pick the time that is best for the most people.

Just looking at the spreadsheet, I think that time is pretty obvious: 15:00 UTC. It’s tied for highest cumulative score, and it has only one 0, from @jasnell who hasn’t updated his availability in months. I’m one of the only two 2s for that time, but I’d rather a single meeting time of 15:00 than alternating between 15:00 and the next-best time, 14:00 (for which I’m a 0). The third-best time is 16:00 but it doesn’t score as well as 15:00 and it doesn’t add any people that 15:00 isn’t already including (other than maybe me and @richardlau, and it probably loses @RaisinTen) so I think the best time for the most people is 15:00.

[mhdawson]

@GeoffreyBooth , I think I'd suggest rotating across 2 times, 15 and 16. It would mean that everybody who has recently updated the sheet except you has at least one 4.