-
Notifications
You must be signed in to change notification settings - Fork 134
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
Next weeks meeting conflicts with Modules Team #748
Comments
It's OK and better to swap the meeting on an as-needed basis. We should endeavor to cancel most of our meetings anyway. Taking that time out of rotation entirely will simply make attendance even worse than it is and result in less fair scheduling. |
If Modules WG is every other week, and Meeting Time C is the one that conflicts with it, we could probably permanently switch our schedule from: Week 1 Meeting Time A ...to this: Week 1 Meeting Time A The downside there is that it makes it more complicated to have a recurring calendar event. Another possibility is to see if switching to rotating through four times works. (That could include one time appearing twice, although @ChALkeR may have to fix up the script to take that possibility into account.) |
@MylesBorins If you haven't updated the spreadsheet to change your availability for that time to 50% or whatever, it might be interesting to see if doing that alters the results of the scheduling algorithm. Probably not, but I'd be curious anyway. Also, once we bring on the next two currently-nominated folks (assuming that happens, which I assume it will, so assuming), we'll may need to re-think the schedule again anyway. |
The script is mostly agnostic to that, so if it would require fixes that would be a one number that defines the max number of timeslots. I will increase that and reiterate. @MylesBorins As for three-timeslot variant, the main premise was that they are all distributed evenly ie have the same share, and having them rotating specifically in Would that solve the issue?
I'll reiterate over the data nevertheless. |
Perhaps we should wait for the new members to fill in their data before reiterating. |
For next week should we just swap the TSC meeting time between next week and the week after? |
@mhdawson SGTM. |
I think yes. Make it so! |
@mhdawson That would mean the TSC meeting would move to 11am ET? +1 on whatever time that is as long as it doesn't conflict |
Calendar updated. Nexte week is now 11 ET, and the following week 3ET, no conflicts. |
My current plan would be to worry about this once the new members have been confirmed, we can get their availability data and then take another look at the meeting times. |
Would making it ACBACB fix that complication? I'm all for schedules that require as little discussion and maintenance as possible, and while moving the occaisonal meeting isn't a huge time sync, its one more administrative drag. If the conflicts are predictable and recurring, it would be good to rearrange schedules to avoid them. |
The current spreadsheet shows that we should just update to 15,16,20 (current are 15,16,19). @MylesBorins would that resolve the issue? |
Discussed in TSC meeting today. No objections to moving the meeting time out 1 our as suggested by @nodejs/version-management Calendar updated, closing. |
Can we change the TSC meeting time? This is now the second time we've had the conflict... is it worthwhile for us to consider permanently changing that time?
The text was updated successfully, but these errors were encountered: