2023-04-04 [16:17:54.0291] Looks like April 18 16:00-17:00 UTC is going to be the winner? [16:18:10.0219] I wonder if we might do weekly meetings, though, instead of every-other-week? [16:18:31.0790] There are quite a few issues open issues that we need to work through [16:34:54.0081] Sure, works for me 2023-04-05 [23:15:45.0626] Works for me too! [03:21:01.0980] For me it conflicts with a meeting, but the meeting can probably be rescheduled [03:23:40.0013] * For me it conflicts with a meeting, but that meeting can probably be rescheduled 2023-04-07 [21:09:02.0776] Chris de Almeida: I think you were made an owner of the TC39 cal? [21:09:14.0925] Is it possible for you to move the new AsyncContext meeting into TC39? [08:01:12.0822] sure. TZ is UTC or... ? [08:04:57.0418] Actually, Jordan helped with this last night [08:09:41.0668] sure -- it appears the meeting IS in UTC. notably, it will not shift for DST. is that an issue for anyone? [08:10:58.0546] Hasn't DST past? [08:11:17.0795] I think it's fine to use UTC since everyone won't shift times at the same… time. [08:12:37.0832] but it means anyone in countries observing DST, will have the meeting at a different time half the year [08:14:07.0117] so for example, for me right now, the meeting is at 11, but in November it will move to 10 and then in March move back to 11 [08:15:57.0927] usually we would want these meetings to observe DST because most of us (I think) are in TZs that observe DST. we don't all change over at the same time, but this usually will only manifest in two meetings per year ending up at a different time for people in one of the TZs [09:00:11.0476] we'd be moving into the left column in November [09:02:17.0186] Let's worry about this in Nov? [09:02:31.0594] Even if we were to schedule this in a different timezone, we're still going to have this headache [09:02:38.0609] Who's DST do we use? [09:02:49.0377] US and EU don't share an end date [09:02:52.0431] China doesn't have DST [09:03:32.0185] US/EU -> two meetings per year ending up at a different time for people in one of the TZs [09:05:25.0360] > <@jridgewell:matrix.org> Even if we were to schedule this in a different timezone, we're still going to have this headache just a question of what would be the least disruptive. what's the utilitarian optimization here [10:58:54.0335] > <@softwarechris:matrix.org> just a question of what would be the least disruptive. what's the utilitarian optimization here My experience is that programming against UTC ends up being more disruptive because conflicts are scheduled in local time. Anyway, agree that we should worry about this in November. 2023-04-11 [09:17:40.0969] FYI -- module harmony meeting has moved to every Tuesday (and duration reduced to 1 hour). as such, there is now a bi-weekly conflict w/ async context meeting. mentioning this as there is some overlap with participants [09:20:00.0088] why was it changed to weekly? [09:21:49.0234] I don't know -- appears to be a decision they came to previously. meeting is going on right now. I can ask if there is time [09:47:08.0564] - quicker iteration - not enough meetings between plenary meetings - reduce duration - have 3 meetings with Kris Kowal prior to plenary 2023-04-18 [10:10:24.0822] For the scheduling of the following meetings: every two weeks (today, two weeks from now, etc.) I'm not available before ~15:00 UTC because it conflicts with another meeting [13:11:57.0951] I briefly sync'd with bakkot on his thoughts on the generator problem. He explained that he'd prefer to see the original context restored after yield returns. He cited his argument at https://matrixlogs.bakkot.com/TC39_Delegates/2023-03-23#L173 . I find Kevin's argument persuasive to me so far, but I feel like I'm missing something in Justin's arguments in the other direction. So let's continue discussing that next week. 2023-04-21 [04:21:14.0966] https://docs.google.com/document/d/1yQy8RNeGXLr99bNpy-7tA1Ch7wN0piekp_-JwxC8FtA/edit# 2023-04-25 [09:00:11.0489] Hey, did we reschedule the AsyncContext meeting? Or was it just cancelled this week? [09:00:32.0683] I think the calendar is not set as a repeating item [09:03:06.0751] I thought we were doing 2-weekly? [09:03:24.0378] * I thought we were doing every-other-week? [09:03:35.0973] The calendar item is still missing next week [09:03:46.0365] * ~~The calendar item is still missing next week~~ [09:03:54.0996] * ~~The calendar item is still missing next week~~ Sorry, notice that it presents [09:04:20.0259] I can open the meeting this week if we're doing it [09:04:53.0005] It's only me and Chengzhong at the moment [09:05:29.0393] I'm fine with skipping today and continuing next week. [09:06:18.0862] (apologies, I got a conflict on the first half hour, as this wasn't in my cal) [09:06:26.0942] Also, if the schedule is every-other-week, maybe we can move to the another week to avoid conflicting with module harmony's call? [09:07:21.0674] Module harmony is weekly now, so it won't help [09:07:34.0727] We _were_ scheduled for the opposite week [09:08:32.0631] > <@yoavweiss:matrix.org> (apologies, I got a conflict on the first half hour, as this wasn't in my cal) It's ok, we didn't start the call actually. We talked about setting the call every week but the calendar item is set as biweekly. [09:12:06.0462] > <@jridgewell:matrix.org> Module harmony is weekly now, so it won't help I see. As Andreu Botella (OOO Apr 25) mentioned that he's not available before 15:00 UTC, does it make sense for all of us to postpone one hour for the call? [09:12:21.0974] > <@jridgewell:matrix.org> Module harmony is weekly now, so it won't help * I see. As Andreu Botella (OOO Apr 25) mentioned that he's not available before 15:00 UTC, does it make sense for all of us to postpone one hour for the call? (if I'm calculating the time correctly) [09:14:47.0243] That works for me [09:16:46.0868] (I'm in NYC this week, and I had to triple-check that *I'm* calculating the time correctly 😅) [09:20:03.0002] Delaying an hour works well for me