-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Alter TSC meeting schedule #134
Comments
Would the suggestion be one of the following:
Personally the 2nd option would make the most sense to me - as that would ensure that any one person could make 2 out of 3 meetings, while also covering every possible pairing of the 3 regions - to best allow cross-collaboration between regions. Taking the timezones you listed @nzlosh - to provide example meeting times that seem to be most accommodating to each paring (I'll give the UTC time, the earliest timezone and latest timezone for each):
The 3rd month doesn't seem the greatest - it would be very early morning in India while being quite late in New York - but there doesn't seem to be any great options that allows both ends of the AMER timezones and both ends of the APAC timezones to still be during waking hours and not actually fall during the night. Which does raise two other issues:
So the other option would be to drop the AMER/APAC session in favor of rotating about the first two - however, I'd personally vote for still keeping it - even if it ends up not be widely attended - at least it would still be there to give APAC and AMER StackStorm members a chance to meet together if they wanted too. Worse case is the TSC meeting becomes 2 times every quarter. Those are some of my thoughts on the matter, and suggestions - but yes 👍 for both proposals - the UTC suggestion surely just makes sense - and the timezone shifting one also does, but I guess would require input on everyone on what times to actually schedule the meetings for. On that second topic, I'd like to to add another suggestion, perhaps people should provide their timezone (and in UTC time) what time frame they'd be able to attend so to help with setting times for meetings, to try and best cover as many people as possible. In my case I'm in the UK timezone and I'd be able to attend anytime between 7am and 7pm UTC. Please note I'm a UK based member, and may have unintentionally shown basis in the suggestions of times above. I made the assumption that the European style of working ~8am > ~6pm applies everywhere and people tend to sleep between ~10pm and ~6am. If any of that is not true, I apologize and meant no offense :) |
I think the idea of fixing on UTC and rotating the time on a monthly basis sounds a good idea. Also UK based so wouldn't be able to make the AMER/APAC session. |
Seconded. |
During the (March 2024 TSC Meeting)[https://github.com//issues/133] there were some attendees missing due to confusion around daylight savings changes in the US Pacific timezone. This is a recurring problem as the local time and US Pacific timezone shifts 2 to 4 times per year.
It was suggested the meeting schedule use UTC timezone which is not affected by daylight savings so that attendees need only take into consideration their own local timezone daylight savings obversvations. A second suggestion was to consider an alternating meeting schedule that would allow participation from people across the globe (America/Europe/Asia) specifically with contributors in Japan and India in mind.
Proposal 1: Use the UTC timezone for all TSC meeting scheduling.
Proposal 2: Use alternating dates to include America and Asia as best as possible. Due to the 16 hour time difference between Tokyo and New York, the available time periods are limited when aligned.
https://www.worldtimebuddy.com/?pl=1&lid=100,2643743,5128581,5368361,2988507,360630,524901,30,1850147&h=100&hf=0
Europe Asia (Tue 09 Apr 2024 09:00:00 UTC)
Europe America (Tue 09 Apr 2024 17:00:00 UTC)
America Asia (Tue 09 Apr 2024 00:00:00 UTC)
This issue is get peoples feedback on the idea, not an official change of the TSC meeting schedule.
The text was updated successfully, but these errors were encountered: