-
Notifications
You must be signed in to change notification settings - Fork 133
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
Review meeting date times ? #809
Comments
Everyone, please also update the |
I wonder if we should also discuss a different day based on the comment by @targos. Possibly a timeslot on Thursday? |
Thursdays would work better for me as well. |
I'm good on both Wednesdays and Thursdays. |
Thursdays work for me. If we do multiple days we'll need multiple spreadsheets |
FWIW, Wednesdays are much better than Tuesdays or Thursdays for me. |
I've added another sheet for Thursday. I have a feeling we are going to need to use 2 days. |
Given the current data, it's likely that we will have either 2 or 3 (out of 3) timeslots on Thursdays instead of Wednesdays. |
@ChALkeR at this point we probably have the data we are going to get. Can you pull generate a recommendation from the data? |
@mhdawson data updated (on the third page of the sheet). Seems like three main alternatives (times not mentioned on a purpose -- those are present in the table, but I don't want the specific timeslots to affect the generic decision we make here). Here, Option 1. Three timeslots (Wed/Thu)
One person at ~40%, one at ~50%, 10 at or above ~60%, 2 at or above ~70%, 5 at or above ~90%. The downside here is that it brings one person significantly below 50% (to 40%) participation. Option 2. Two timeslots (Wed/Thu)
7 persons at ~50%, one at ~70%, everyone else (11) at above 90%. The downside here is interaction form -- in particular, there are going to be more pairs of people who are very unlikely to ever be present on the same call. Option 3. Two timeslots (Thursday only)
6 persons at ~50%, two at ~60%, one at ~70%, everyone else (10) at above 90%. Has the same problem as Option 2 -- there are 6 people each of whom would be able to attend only one meetings, and they segment into two groups, so people from different groups won't be ever present on the same meeting. |
@mhdawson One more note: it seems that not everybody confirmed Thursdays yet, and I see at least one person whose data has the potential of shifting the optimal timeslots significantly there. |
We should probably add availability data for @codebytere and @mmarchini and see if anything changes. (The other two current nominees, Ruben and Gireesh, are already in the spreadsheet. And the recent emeritus, Sakthipriyan, has been removed from the spreadsheet. So the spreadsheet is up-to-date otherwise.) |
I'll email them the link along with the "please do not share this information" caveat. |
Also, daylight savings time change happens in the U.S. this weekend, so everyone here will probably have to update their data again. Whee! |
Ok given the daylight savings time can we ask that everybody @nodejs/tsc updates their entries and we'll look at the results in a week. Hopefully, we'll have data from @codebytere and @mmarchini as well as updates from the rest of the TSC by then. |
@nodejs/tsc I think we'll all have shifted (if a shift was going to occur next week). Please make sure to have updated your entries by end of this week. @ChALkeR can you do another pass at good times next monday? |
@ChALkeR ping? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@mhdawson sorry for the delay -- recent events stir everything. Two main variants now: Option 1. Two timeslots (one day)6 people at about ~50%, 3 at ~60%, 1 at ~70%, all rest above 90% (10). The positive side is that everyone is at almost 50% or above. The downside is that there are at several pairs of people who are likely to be never present on the same meeting together.
Option 2. Three timeslots (two days)Two persons at ~40%, one at ~50%, all rest above 60% (8 above 90%). The positive side is that minimum interaction is higher -- each two people can have some possibility of meeting at a same timeslot. On the downside, this makes things harder for two people, bringing them from ~50% down to ~40%.
Times not included on a purpose to avoid unintended bias, but one can look them up in the table on the third page (by searching for matching blocks). |
My opinion is that taking people down from 50% to 40% is not worth the benefit of having greater possibility of interaction in meetings. If it was 90% to 80% that might be different but those at 50% are already challenged in terms of the meeting times and going down even further I don't think would be the right choice. |
@mhdawson To clarify: the difference is not just in bringing two people from 50% to 40% vs increasing interaction, there is a bunch of differences between the two options, e.g. the second one also brings three people from 50% to 65% and reduces stdev. But yes, that might be not worthwhile. Let's have a quick reaction-based poll here:
I personally abstain, mostly because I prepared the poll. |
It's not exactly clear what are the timeslots. I think that'd be helpful. |
@mcollina I did not mention the timeslots on a purpose, to not unintentionally bias people towards their personally convenient timeslots as opposed to what option seems more appropriate. One could look them up the spreadsheet as I mentioned above, but I'm not sure if that is a good idea. I'm not voting here personally because I might be biased. |
@ChALkeR Is it safe to assume you explored a 4-timeslot option but that it didn't have any superior options? |
@Trott No, that didn't happen because I used the web version that has that disabled. |
@Trott, actually, there is a number of 4-timeslot variants which seem better than both of those. |
E.g. this one:
One meeting at 14 UTC on Wednesday, the remaining ones on Thursday at 15, 20, 21 UTC. Average is one percent lower, but this looks better than at least the first option. WDYT? |
Ok, given that a lot of people weighted in on the 1/2 option and there is almost a draw, also we have a 4-slot option now, let me reveal the times involved. Timeslots:
Meeting averages
Participation percentages:
Interaction percentages:
|
It looks like the 4-slot variant is better in general, so I'm going to propose that as the main variant. |
I'm good with everything, however if the 4 variants is chosen it's better we alternate the times like so: 14 UTC on Wed So that the people that can meet earlier in the day have a chance to meet every other week anyway. |
Sounds good to me. |
SGTM |
@mcollina In the post above, I mentioned this order:
I don't see much difference between the two of those, anything of those two should work I think 😃. |
I did not understand what 45 and 44 where at all. |
@mcollina Ah. Time in hours minus 00:00 UTC on Wednesday, that's how the timeslots are numbered in the spreadsheet. |
The 4 time slots + thu are way better for me. Too many standing mtgs on Wed that I can't move :( |
Calender updated, closing. |
Next meeting: Thursday, 16 April 2020, 15:00:00 UTC |
May be time to review the day/times for the TSC meetings. #808 (comment)
@targos sounds like Wednesday is not good for you at all. @nodejs/tsc are people open to looking to move to another day? From past conversations I think we'd tried to keep all instances on the same day is that still the case or should we consider different days in addition to different times?
The text was updated successfully, but these errors were encountered: