Scheduling Meetings

[Trott]

@nodejs/ctc

As the CTC expands to include an expanding set of timezones, having a meeting at the same time every week becomes less workable.

There is currently a proposal to add @thefourtheye to the CTC. The current CTC meeting is at 1:30 AM in their local time. It's also at 5AM for a current member.

Here is a draft proposal for something to try to mitigate the meeting scheduling issues (or at least distribute the pain a little more equitably).

Fun fact/aside: The time zone with the most CTC members is now Eastern Time (New York), and no longer Pacific Time (San Franscisco). Take THAT, Silicon Valley!

Without further ado...

The Proposal

• Have a voice conference meeting (the type of meeting we currently have weekly) once a month on the first Wednesday of the month. (Day is determined by UTC time.)
• Other meetings can be scheduled ad hoc as necessary, but we should do everything we can to have decisions and discussions in GitHub, email, and other asynchronous communication channels.
• The first meeting time should be 16:00 UTC.
• Each subsequent meeting will start four hours later (but always on Wednesday in UTC time). So 20:00, midnight, 04:00, 08:00, 12:00. At six months, it would repeat again.
• The plan should be re-evaluated every three or six months.

Here's what the next six CTC meetings (after the one that is happening this week) would look like with this plan. (You may need to scroll right to see times for Sydney, Tokyo, etc.)

UTC-time	San Francisco	Denver	Chicago	New York	Amsterdam	Moscow	Chennai	Tokyo	Sydney
Wednesday, October 5, 2016 at 16:00:00	Wed 9:00 AM *	Wed 10:00 AM *	Wed 11:00 AM *	Wed 12:00 Noon *	Wed 6:00 PM *	Wed 7:00 PM	Wed 9:30 PM	Thu 1:00 AM	Thu 3:00 AM *
Wednesday, November 2, 2016 at 20:00:00	Wed 1:00 PM *	Wed 2:00 PM *	Wed 3:00 PM *	Wed 4:00 PM *	Wed 9:00 PM	Wed 11:00 PM	Thu 1:30 AM	Thu 5:00 AM	Thu 7:00 AM *
Wednesday, December 7, 2016 at 00:00:00	Tue 4:00 PM	Tue 5:00 PM	Tue 6:00 PM	Tue 7:00 PM	Wed 1:00 AM	Wed 3:00 AM	Wed 5:30 AM	Wed 9:00 AM	Wed 11:00 AM *
Wednesday, January 4, 2017 at 04:00:00	Tue 8:00 PM	Tue 9:00 PM	Tue 10:00 PM	Tue 11:00 PM	Wed 5:00 AM	Wed 7:00 AM	Wed 9:30 AM	Wed 1:00 PM	Wed 3:00 PM *
Wednesday, February 1, 2017 at 08:00:00	Midnight Tue-Wed	Wed 1:00 AM	Wed 2:00 AM	Wed 3:00 AM	Wed 9:00 AM	Wed 11:00 AM	Wed 1:30 PM	Wed 5:00 PM	Wed 7:00 PM *
Wednesday, March 1, 2017 at 12:00:00	Wed 4:00 AM	Wed 5:00 AM	Wed 6:00 AM	Wed 7:00 AM	Wed 1:00 PM	Wed 3:00 PM	Wed 5:30 PM	Wed 9:00 PM	Wed 11:00 PM *

[jasnell]

I am very much +1 on a rotating meeting schedule that is fair to non-north american participants but I think once a month is a bit too spread out. Perhaps every other week would be better and if necessary we can stretch it out again.

Also, if we do alter the scheduling, we will need to make sure that members are being more proactive about engaging in the GitHub conversations. I believe @Fishrock123 pointed out in one of the several threads on this that such a change runs the risk of making it more difficult for us to be decisive when necessary.

Last, a suggestion: could you move this into a pull request with the schedule added as markdown file in the repo?

[Fishrock123]

Perhaps every other week would be better and if necessary we can stretch it out again.

I think this would be a better starting point.

Have you seen how much stuff can sometimes come to us to discuss? Also, GitHub still does not have good enough tools for corralling specific people to specific conversations above all else.

I like the idea, but I don't think an immediate move to these is tenable.

[addaleax]

Maybe I’m just a bit oblivious, but: what is the connection between rotating meeting times and less frequent meetings? If we’re going to have less attendance due to the meeting times anyway, wouldn’t holding fewer meetings make that problem worse?

[ChALkeR]

@Trott, while rotating meeting time by the exact amount of hours might look fair at a first glance, it could lead to a situation when no one is happy about some meeting times.

For example, while one might think otherwise, I am pretty comfortable with the current meeting times at 11:00 PM Wednesdays in my local timezone (those are in fact close to ideal for me), but I would not be comfortable with meetings at 11:00 AM Wednesdays to the point that I won't be able to participate in those, at least until the end of this calendar year (yes, I see that the proposed plan has those only next year, this is a theoretical example).

Note: this is not against rotating the time so that other members could be more happy, just to show that it's probably better to ask everybody, not introduce some even distribution that looks fair for all.

[Trott]

@jasnell wrote:

Perhaps every other week would be better and if necessary we can stretch it out again.

Sure.

@addaleax wrote:

what is the connection between rotating meeting times and less frequent meetings?

It's two-fold:

• It acts as stronger encouragement to use the issue tracker or email when possible.
• A weekly meeting that takes place at the same time is easy to schedule for. A weekly meeting that is at a different time each week seems more likely to end up with people not knowing when the meeting is, accidentally scheduling conflicts, etc. A monthly meeting at a different time each month seemed more manageable. Put it in your calendar a month ahead of time or whatever.

But that's OK, I'm fine with making the meeting every two weeks or keeping it every week (if that's the consensus) or whatever.

@addaleax also wrote:

If we’re going to have less attendance due to the meeting times anyway, wouldn’t holding fewer meetings make that problem worse?

Yes, unless we get serious about using the issue tracker more and the meetings less. It seems like this is totally do-able but that we lack the will. (People who have not yet voted or abstained on the Async Hooks EP, I am looking in your direction.)

@ChALkeR wrote:

Note: this is not against rotating the time so that other members could be more happy, just to show that it's probably better to ask everybody, not introduce some even distribution that looks fair for all.

I considered that issue but I decided to go with straight rotation for simplicity. The idea of gathering information about scheduling and desirability of time slots from 18 people and trying to make sense of it seemed daunting. But rethinking now:

• 13 of the 18 members are in North America, in four contiguous time zones. It seems incredibly unlikely that daytime and early evening times in those time zones are going to be unworkable. (The time we use now is afternoon in North America.) So, basically, there are 3 meeting times that we probably don't even need to ask about. (9AM, 1PM, and 4PM Pacific Time are all great for me. Maybe I'm projecting? North America folks, speak up on those times, please. Good for you, or at least good enough? Remember to adjust for time zone if you are not on Pacific Time.)

That leaves just 3 meeting times that are likely to be problematic for folks in North America:

• UTC 4:00 which is 8PM on the west coast of the US, so is probably good for at least a few of the 5 people in that time zone. (Works for me, especially if it's just once every 6 weeks or 12 weeks or whatever.) It's also 3PM for @rvagg and 1PM for @shigeki. (Can you two confirm that those times would be good for you?)
• UTC 8:00 which is midnight in San Francisco and 3AM in New York. This one is likely to be terrible for most North Americans, although I can make it work (again, especially if it's just once every 6 or 12 weeks). That works out to 9AM for @bnoordhuis and @addaleax, 11AM for @ChALkeR, 5PM for @shigeki, and 7PM for @rvagg. If it's a good time for three or four of those folks, it's still probably worth doing if we can get another 5 or 6 people in North America to do it. This is the diciest of the meeting times, so you may have a point that this one is worth skipping. I will note, though, that it could be awesome for @thefourtheye as well, as it's 1:30PM in Chennai. Not sure how to make the determination of workability this far in advance. Might have to wait until it's upon us and figure out who is willing to make it work, and make a decision based on that.
• UTC 12:00 which is 4AM in San Francisco and 7AM in New York. This one gets a little tricky too. There are six CTC members on New York time, so if most of them can make it, we're in pretty good shape. It's 11PM for @rvagg so he may opt out. It's 9PM for @shigeki, 5:30PM for @thefourtheye, 3PM for @ChALkeR, and 1PM for @addaleax and @bnoordhuis. Would only need two or three of those folks to make the time workable, as long as enough of the Eastern Time (New York, etc.) folks and maybe @mscdex (for whom it would be 6AM) can make it work.

Also: I'm up for trying the times and deciding a time doesn't work based on actual attendance results. I wouldn't be surprised to find that people may say "yes" to something and then not do it ("I thought I could get up at 5AM but I just can't") and vice versa (someone might say "no" to a midnight meeting but if it ends up being scheduled at midnight, they might make it work anyway).

[bnoordhuis]

For me personally UTC 0600 or even 0530 would work too, that's 7 or 8 AM local time, depending on DST. @addaleax Are you a morning person?

Probably still a terrible time for the people on the East Coast, though.

[addaleax]

@addaleax Are you a morning person?

That would be a “no”, but if Rod can make the current times work, I could probably live with it too.

[Trott]

As of this writing, 8 CTC members and two regular observers have filled out the Google doc that @ChALkeR set up. Based on that limited data, UTC 16:00 and UTC 20:00 seem like obviously workable times, but nothing else looks clearly workable. That doesn't mean other times aren't workable, as we lack a lot of data.

So, the possible three approaches at this point:

• Just have the meeting at the rotating times and see what works and doesn't.
• Start rotating with just those two times as a pilot.
• Solicit other responses from people.

Unless someone feels strongly that we ought to do that first option, I'm going to try to push for doing both the second and third option. Basically: Start rotating with those two times, and collect more data about other times to add other times if they will in fact work.

I'm taking a somewhat intuitive approach to what constitutes "workable" based on the data, but if someone wants to come up with concrete criteria, I'm happy to switch to something more rigorously defined.

EDIT: More careful review suggests rotating between those two times without more information is probably not the way to go. Based on the information we have now, there is only one person for whom 16:00 UTC is any better than 20:00 UTC, and it's bump up from "inconvenient" to "tolerable". If more data comes in that indicates it's a much better time for some other people, then it may be worth piloting. So for now, I'll lay off on the "let's do this!!!!!" approach.

[Trott]

So, soliciting responses from other people: I'll send an email to these three individuals, but it would be especially useful to get info from @shigeki, @rvagg, and @thefourtheye. Those are the people who have not responded who are also not in North America. Email to follow...

[Trott]

We now have data from all CTC members except @chrisdickinson.

So here's my new proposal for something to try out for a month or two and re-evaluate.

• Use only meeting times that have a median score of 3 or higher based on the data we have for current CTC members and the existing CTC nominee. (3 = estimated 80% or greater ability to attend at that time)
• Keep the current meeting time as one meeting, to keep things simple for now.
• Add a second meeting time to see how rotation does or doesn't work out.
• A CTC member (including our current nominee so we don't have to do this all over again in a few weeks) should have at most one meeting time that they are likely to miss. In other words, if the current time is bad for a member, the second meeting time should be good (3 or higher).

Given these constraints, it would seem that UTC 16:00 and 20:00 would be the way to go.

16:00 is bad for Rod, Anna, and me. Everyone else has it as 3 or higher.

20:00 is bad for Ben, Shigeki, and Sakthipriyan. Everyone else has it as 3 or higher.

If we wanted to try this for a short time, here's how our meeting schedule would go after this week.

UTC-time	San Francisco	New York	Amsterdam	Moscow	Chennai	Tokyo	Sydney
Wednesday, October 12, 2016 at 16:00:00	Wed 9:00 AM *	Wed 12:00 Noon *	Wed 6:00 PM *	Wed 7:00 PM	Wed 9:30 PM	Thu 1:00 AM	Thu 3:00 AM *
Wednesday, October 19, 2016 at 20:00:00	Wed 1:00 PM *	Wed 4:00 PM *	Wed 10:00 PM *	Wed 11:00 PM	Thu 1:30 AM	Thu 5:00 AM	Thu 7:00 AM *
Wednesday, October 26, 2016 at 16:00:00	Wed 9:00 AM *	Wed 12:00 Noon *	Wed 6:00 PM *	Wed 7:00 PM	Wed 9:30 PM	Thu 1:00 AM	Thu 3:00 AM *
Wednesday, November 2, 2016 at 20:00:00	Wed 1:00 PM *	Wed 4:00 PM *	Wed 9:00 PM	Wed 11:00 PM	Thu 1:30 AM	Thu 5:00 AM	Thu 7:00 AM *

Then we could re-evaluate and possibly tweak at or before our November 2 meeting.

Asterisk (*) in the above table means the time is daylight savings time in that location. That's why the time changes for some places even though the UTC time remains constant.

Before you leave a comment or question: All the data is in the Google spreadsheet. If you want to know how it might work if we do this or that differently, try to look at the data and figure it out. Please resist the temptation to make a comment/question here and leaving it at that. Thanks.

Also, to head off the "Why not add a third meeting time?" question: I don't believe it's possible to have three meetings where someone does not have at least 2 meetings that are bad (score of less than 3) for them. Feel free to look at the spreadsheet and try to prove me wrong. I'd be happy to be shown that I'm in error on this. I'd prefer three meeting times, all things being equal. But I don't want anyone to be a lock for missing 2 out of every 3 meetings. Ergo: two meeting times.

[rvagg]

Ouch, both slots suck for @shigeki, even though we are hitting one of his 3 slots. For the record, the existing slot is not awesome for me either, it's 7am now which is bearable but will slip back to 6am post-DST so I'll have to choose between 2am and 6am.

Unfortunately I don't see better options, I think you've done a great job of dissecting this all @Trott. A 3rd slot might be nice to add at a later date but you're right to pick just 2 to start with, perhaps 2 will even prove to be too difficult!

[Trott]

Ouch, both slots suck for @shigeki, even though we are hitting one of his 3 slots.

I thought that too but decided I should not second-guess anyone's statements about their own availability. Like, if 1AM local time is a "I can be there 80% of the time" slot for Shigeki or anyone else, who am I to say it's not a good time for them?

Part of re-evaluating in a few weeks will probably include everyone revising their assessments of times that do or don't work for them. I know daylight savings will definitely have an impact for me. Moving something by one hour can be the difference between "I can make it 100% of the time" and "I will usually miss that time".

So when DST makes that time bad for you, Rod, we may be able to consider pushing it later (which will also help Shigeki at that time).

For the record, Rod, these times are the worst on balance for you of anyone. You're the only person for whom one of these times is a "Nope, I will never be able to make that time, it's impossible" slot. So if you can make it work, that's a good sign. :-D

And yeah, if we can't make 2 time slots work, then it may be back to the drawing board. I can't think of too many great options there either. Stick with one time (which is great only for the people that it's already great for) or ad hoc scheduling (which does not seem workable, although maybe it can work with some extensive tooling/automation).

[Trott]

Related: It hasn't been perfect, but I think using GitHub and email to gather votes has proved workable. What seems to be less certain (at least to me) is how to use asynchronodus communication to deal with the more typical situation where we don't need a vote but just need consensus. Maybe the thing to do is make it similar to what we do on pull requests in the main repo, so something like:

• open an issue here
• @-mention the CTC
• explain the proposal/issue
• say we're leaving it open for 72 hours for comments
• If two or more LGTMs from other CTC members + no explicit "I'm opposed", then it is approved.
• If there are any CTC members giving -1's, thumbs down, or explicit opposition to the proposal, then a conversation ensues until either the proposal is dropped or the objecting members are persuaded. If there is an extended impasse, then someone can make a call for a vote per the rules already in our governance docs.

[bnoordhuis]

I like that proposal, sounds workable.

[mhdawson]

LGTM, (times are good for me so easy to agree)

[Trott]

There was consensus (no objections) to this at the meeting earlier and no objections here. So, next week's meeting will be four hours earlier than this week. I'll open a PR to get the schedule into the CTC README. Meanwhile, closing this. (Feel free to re-open if you think that's premature.)

[williamkapke]

The calendar has been updated. I think I got it right ;)