Repository navigation
Proposed New TSC Meeting Schedule #444
Description
Current meeting times in UTC are 12:00, 17:00, and 22:00.
End of the year seems like a good time to review the meeting times. (I think a six-month cadence on that is probably about right.)
If nobody on @nodejs/tsc has any changes to make to the availability spreadsheet then the fairness algorithm I use to suggest times is recommending UTC 00:00 (midnight), 13:00, and 20:00.
| UTC | Berlin | Moscow | Chennai | Beijing | Sydney | San Francisco | New York |
|---|---|---|---|---|---|---|---|
| midnight | 1:00 AM | 3:00 AM | 5:30 AM | 8:00 AM | 11:00 AM | 4:00 PM | 7:00 PM |
| 1:00 PM | 2:00 PM | 4:00 PM | 6:30 PM | 9:00 PM | midnight | 5:00 AM | 8:00 AM |
| 8:00 PM | 9:00 PM | 11:00 PM | 1:30 AM | 4:00 AM | 7:00 AM | 12:00 PM | 3:00 PM |
If you want to influence the time slot selection, please update your row in the spreadsheet and let me know to re-run on the new data.
(And, of course, the algorithm is just an algorithm. We can debate/discuss appropriate times and don't have to accept these. Matteo and I already had a talk in IRC while I was typing up this issue!)
Activity
[-]TSC Meeting Schedule[/-][+]Proposed New TSC Meeting Schedule[/+]ChALkeR commentedon Dec 18, 2017
Looks good to me (LGTM).
What is the exact proposed schedule, i.e. starting with which date should it become effective (assuming next+1 meeting?) and at what timeslot of those three should the first meeting using this new schedule happen?
joyeecheung commentedon Dec 18, 2017
LGTM
mhdawson commentedon Dec 18, 2017
LGTM
rvagg commentedon Dec 19, 2017
Works really nicely for me but perhaps that's not a good thing because there's only one of us down my way and in this schedule Europe, Russia and Asia get worse time slots than I do. The 5am Pacific (1pm UTC) is a concern too, lots of black, red and orange in that column and I have I reckon that reds and oranges are more likely to be black in practice when a 5am meeting rolls around (speaking from lots and lots of experience with regular early morning meetings!). Moving it an hour later would likely knock me out but I think we'd get more likely attendees in that slot. Both the sum and average of the ratings in that slot go up by quite a bit if moved later by an hour.
jasnell commentedon Dec 19, 2017
I'd prefer to keep the current times as they are.
fhinkel commentedon Dec 19, 2017
I think everybody except the East coast, has at least one time slot that's in the middle of the night. Chennai has only one slot that I'd consider not in the middle of the night. Is that OK?
mcollina commentedon Dec 19, 2017
I had a chat with @Trott about this. Unfortunately, we are truly global group and this means it is fine if we join only 1 every 3 meetings, with some incovenience to join 2 over 3.
The current criteria are exactly how @fhinkel frames them in #444 (comment): one meeting in working hours.
This means it is fine if we are never all in the same room. If we want to optimize for maximum attendance it's a completely different metric.
Anyway, I see more people have updated, so it's time for an update @Trott.
Trott commentedon Dec 19, 2017
Er...I think you mean it is fine if we miss 1 out of every 3 meetings.... At least, that's been what I've been using as a rule of thumb....
Trott commentedon Dec 19, 2017
Re-running with updated data changes the results significantly. UTC times proposed are now, 12:00, 20:00, and 22:00.
This is the same as our current times except that the current 17:00 UTC meeting is shifted three hours later to 20:00 UTC.
I do like that it's a single change to our current schedule rather than a completely different schedule.
ChALkeR commentedon Dec 20, 2017
LGTM as long as that's the optimal result.
I also think that the algorithm itself that selects the optimal dates (i.e. the code) should live inside this (or some other
nodejs/*) repo, so that it could potentially be updated using the regular process. That should not block this issue — that's a separate one ;-).jasnell commentedon Dec 20, 2017
Since I see you thumbs'd down my comment @Trott, let me clarify... the proposed new schedule would work for me, but I have a personal preference on keeping the current one as the times are actually far more convenient for me. I certainly don't want to block changing the schedule tho if it makes it more convenient for others.
(and just as a side note, using the thumb's down when someone expresses their personal preference when feedback is explicitly being asked for does little to encourage those folks to offer their input in the future).
Trott commentedon Dec 20, 2017
@jasnell That's fair. Sorry about that. In the future, I'll respond instead with comments along the lines of "This comment needs more information to be useful/actionable. Can you elaborate?".
I had been thinking that I was OK with using thumbs-down when "established" folks leave these sorts of "+1" or "-1" comments. Clearly, that was a miscalculation. In retrospect, I failed to consider that I myself am "established" and therefore a thumbs down from me is likely to be more disconcerting than a thumbs-down from a GitHub handle you've never heard of before. And the "established" thing aside, there's probably also something more troubling about a thumbs-down from someone you know than someone you don't.
I'll go back to basically never using thumbs-down (except for when specified for voting and on egregiously bad posts such as trolling behavior), which was pretty much what I had been doing.
Thanks for the feedback.
Trott commentedon Dec 21, 2017
Because the proposal has changed, I'm going to close this and open a new issue.