Fetch date from Google Calendar instead of manually set in Action

[mmarchini]

The current script used by most WGs gets the date from the Node.js calendar, which minimizes the chances of the meeting times being out of sync. It would be good if the Action could optionally sync with the calendar instead of manually setting the date in the Action.

[bnb]

Huge +1.

In talking this through with @mhdawson, I realized it's probably possible to just pull the public ICS file and then do the work off of that. Using ICS also effectively makes it generic and usable with any calendar system beyond just Google Calendar.

There's a seemingly well maintained/used module called node-ical that we could use.

[wesleytodd]

While I see the point, that means that you don't have a PR and code change to change the date/time, which is why I initially designed it this way. Not everyone has access to the calendar, and this current way means someone propose a time change without it.

IMO, this is the better order of operations. But if everyone else wants it this way, I wouldn't block it.

[bnb]

That's fair. I do think that if folks can't access it in a way that is serving their needs then we should ensure we're correcting that. It would be awesome if there was a companion action that managed the calendar (i.e. !meeting postpone 1 day or !meeting in 1 week), though the OAuth with Google for Calendar is a PITA.

[wesleytodd]

I do think that if folks can't access it in a way that is serving their needs then we should ensure we're correcting that.

Do you see another way to do this which would enable folks to manage it reasonably? I know that I just kept pinging Michael every time, which doesn't seem scalable lol. Maybe there is already a simple way, but to me it seems like merging a PR with the schedule in it is the best long term way.

It would be awesome if there was a companion action

Any reason that would not just be a feature of this action? You could have it run on comments in a meeting issue and then just update the issue, notes and calendar in one go.

OAuth with Google for Calendar is a PITA.

Yeah, this is certainly an issue. If it is an insurmountable one then it makes sense to at least get the other method working.

[mhdawson]

We can get people access to the calendar, we should probably have the regular chair for any meeting having access. I'm happy to make an occasional change but don't want to be in the middle.

[bnb]

Do you see another way to do this which would enable folks to manage it reasonably?

Adding folks more liberally is one way. AFAIK there's not a mega barrier right now other than asking in the right place.

Maybe there is already a simple way, but to me it seems like merging a PR with the schedule in it is the best long term way.

I agree that making this more accessible would be entirely ideal. If it were in code/config that wrote to the calendar, that would also generally just solve the problem of having to have calendar maintainers at all, which imo is something to strive for - reducing manual inputs and synchronous work as much as possible is 100% ideal.

Any reason that would not just be a feature of this action? You could have it run on comments in a meeting issue and then just update the issue, notes and calendar in one go.

No reason other than initial config complexity. I'm not sure how a single action that does cron and payload parsing would look, but I'm sure it's doable.

Yeah, this is certainly an issue. If it is an insurmountable one then it makes sense to at least get the other method working.

I briefly chatted with @JustinBeckwith about this a bit ago. He had some pointers but, to be totally honest, how to get them to work within an Actions flow was a bit above my head. It might be worth following up with him at some point to see if it's doable ❤️

[JustinBeckwith]

👋 hey y'all, I'm more than happy to help out here with the google oauth rigamarole. The calendar you're trying to access - is this tied to a GSuite account? If it is, we can create a service account and set up delegation on it, so it can act on behalf of a user. After that, I think a good ol service account flow should work fine.

In terms of using the API itself, that's usually the easy part once you have auth all sorted. Either way - I'd be happy to hop on a chat with someone to walk through the auth bits, and then I'd even be happy to take a crack at the code if you want to point in a direction.

[bnb]

@JustinBeckwith I believe it is / could be currently tied with the Node.js Foundation's old GSuite but as far as I know the OpenJS Foundation would like to get rid of that if possible. I'm not sure what the status is.

[bnb]

Thinking about this a bit more, assuming consumers of the Action use GSuite if they want to hook up the Google Calendar functionality is reasonable.

[wesleytodd]

FWIW, I fully agree that the iso interval standard is horrible. That said, the fact that this has sat here for so long is a testament to how it is actually difficult to couple to a google calendar event and the current solution is comparatively simple in that regard. Also, since technically this action is really just a glorified todo list generator, I feel like coupling to the google calendar api (assuming the "instead" in the issue title means replace the existing functionality) is limiting it's usage.

I wonder if we could just have some "presets" shipped with the action which would work for the most common schedules where they just need to add the time, but the interval was handled for them? Something like:

schedules: 'WEEKLY:2022-6-20:11:00:00.0Z'

If we supported some custom shorthand for the iso spec we could solve the worst of the UX problems with this action while not adding near as much complexity as coupling to a google org/user and the specific calendar invite.

Another idea would be to write a little import helper as a separate action. So like one which poll's the calendar but instead of using that to directly create the issue, it could open a PR to change the schedule in the main action. This would mean that there was clean separation of the two parts and also that there was a PR audit trail which could be used for proposed scheduling discussions (which was my main design decision originally here).

IDK, again I am not arguing against this being a real issue, just thinking about it since I am installing the action in a project this morning.

[wesleytodd]

I am just going through the issues since we have need of something for Express and want to re-iterate why I think this is a bad idea:

1. Calendar access is outside the normal contributor flow which is entirely on GH
2. It means we need additional administrative work to manually manage the calendar invite and user permissions
3. To keep things like the video chat links updated still means we need "write" on the calendar (afaik the current bot for node doens't do that, but I think it should based on how many times folks say the link is broken/outdated)
4. Users without a google account (this ones a bit of a strawman argument, sorry) cannot be calendar managers

Obviously I had not had much time to work on this over the past few years, so I don't mean any of this to block if folks waned to work on that. If everyone really agreed and wanted to go that route I will likely just fork this into the Express org so we can have one which is fully Github driven (and an aside, this also makes a great todo list generator in this form without any calendar integration).