Propose Arbitrary Meeting Time #18
Conversation
* The 9am meeting time is 4am New Zealand time * It may be exclusionary to other time zones * This part of the year is the worst for Time Zone overlap for myself and PTZ specifically (dual DST offsets) * I have no data to back up this meeting time * I would like to see more folks in diverse time zones able to attend
|
Would evening work better for folks who can't cut time out of work? Is the expectation that ChefInc employees will attend during work hours as part of some responsibility? |
|
No Chef Software employees are mandated to attend (since it's a community meetings, and communities is people, no companies.) The original time was picked for having easy overlap with Europe. I think moving it to 12 PST actually sets up the best compromise: I'm 👍 |
|
@fujin cross-post to chef@ and chef-dev@ email lists, please. |
|
There's no good way to accommodate everyone, I'm still out at 12 PST because that's 05:00 GMT+10 (Melbourne, Oz) |
|
Yep, 0700 local time for me (NZ). 0500 is rough for Australia, which I would imagine there are more Australian operators online than NZ, that is kind of what I'm trying to gauge with this -- thanks for the feedback! |
|
👍 will be pretty late for India, Singapore.. rest of the APAC. But we dont have many folks from there.. do we? |
|
A suggestion from "Joseph Anthony Pasquale Holsten joseph@josephholsten.com" on the ML: Could be a way? One earlier meeting, one later one, bi-monthly? |
|
Yeah, that's the only way you can sensibly cover US/EU and US/APAC. But it might be interesting to try and gauge the numbers of interested parties in these regions to see if it's worthwhile supporting them(/us). |
|
@pdf What do people think about going 1 hour later, 1pm PST? That makes it still in the range of possible (late at night, but possible) for Europe, early for the australians... |
|
@adamhjk is there a specific reason we chose Friday for the last one? If we move this to later for EU, we should probably at least choose a day where we're less likely to cut into people's weekends. |
|
easy to move to a different day - I choose Friday because it was open on my calendar. |
|
How about a surveymonkey poll with a half dozen different times / time zones so we could see how much of a problem different time zone differences are/gauge the interest from different time zones? |
|
What's the service that lets you vote on preferred times for an event? |
|
@danielsdeleo doodle is the popular one. |
|
Cool, either of those is fine with me. Does doodle translate to your timezone? |
|
@danielsdeleo apparently so: @adamhjk I think we're getting into the realm of making it inconvenient for both APAC/EU at that stage. I think the multiple meeting option is likely to work better, but again, whether that's worth doing will depend on how much interest in involvement there is from those regions. |
|
Please complete this survey to let us know which day works best for you and which timezone you're usually in. https://www.surveymonkey.com/s/QQ995YN Thanks! |
|
Not a huge fan of making this at 9PM UTC on a Friday night, I can see that resulting in an annoyed spouse. If it's going to be at 9PM UTC, I'd vote for another weekday. Added my prefs to the survey :) |
|
I agree with @jonlives, if we are going to go late in the day for anyone near UTC, it would be better to move the meeting to a different weekday. |
|
Yep, I brought this up with @adamhjk in a different forum, I think if it ends up being late in the day UTC, then we should limit to Monday - Thursday. |
|
This was discussed during the IRC meeting on July 25, 2014. No time stood out as significantly better than any other. It was agreed to keep the meeting at 9AM Pacific Time but to move the meeting to Thursdays. |
- We've never done most of what we agreed to do. - We argued out a few points in #77 that we should capture 1. we decided that functional arguments foo("bar", "baz") are better than method chaining, and this was incorporated into the Chef 12 attributes updates. 2. we decided on strings over symbols in the arguments. 3. we also decided that RFC #18 needed to be amended because the implications of foo("bar.baz") were poor. - This also argues for the addition of an option (-F offhand blindly copied from awk, dunno if that'll really work) to deal with cases where '.' as a field separator causes issues -- because typing arrays on the command line is incredibly poor UX and nobody has bothered to implement it. - This officially demotes the dot-syntax to a commandline workaround, and pushes *argv style / array formatting to the forefront for ruby APIs.
and PTZ specifically (dual DST offsets)