Higher friction for one-off meetings or one-off invitees.

[joshtriplett]

An observation from a meeting today:

With the previous system of shared Google calendars, it was easy (for someone on the team with the appropriate permission) to add a one-off meeting, and expect that it'll show up on everyone's calendar. Switch to calendar tab, create meeting in the appropriate calendar, done.

Similarly, with the previous system, it was easy to add people to a single invite (whether recurring or one-off), such as if they were going to have a topic in a given meeting.

With this new system, both of those are more complex and high-friction operations, with enough activation energy that empirically they're failing to happen.

And as a result, there's also a temptation to devolve to using individual calendars, which is what we used to do, which has the problem that then other members of the team can't manage an event if the person who originated it is unavailable.

[davidtwco]

Both of these are definitely issues with these calendars. We could probably build some tooling that would commit to this repository with new events, perhaps an email address that you could invite that would add it here (this is similar to @nikomatsakis' ideas around calendars if I'm not mistaken).

[joshtriplett]

On Tue, Feb 20, 2024 at 03:41:19AM -0800, David Wood wrote: Both of these are definitely issues with these calendars. We could probably build some tooling that would commit to this repository with new events, perhaps an email address that you could invite that would add it here (this is similar to @nikomatsakis' ideas around calendars if I'm not mistaken).

I would like to suggest that I'm not sure if we want to be inventing a new calendar management tool and adding all the features people expect of such a tool. Is there some way we can make it possible for people to use the calendaring tools they're *already* familiar with, and all the capabilities of those tools (e.g. adding invitees, editing meetings, adding attachments, creating one-off meetings) to manage a shared calendar, orthogonally to whatever mechanism we use to make the resulting .ics more widely available to people?

[davidtwco]

Is there some way we can make it possible for people to use the
calendaring tools they're already familiar with, and all the
capabilities of those tools (e.g. adding invitees, editing meetings,
adding attachments, creating one-off meetings) to manage a shared
calendar, orthogonally to whatever mechanism we use to make the
resulting .ics more widely available to people?

I understand why this is desirable and I'm in favour of having something like it. It would be possible to do something like this but it would be a completely different approach to what this repository has taken.

I designed this around the compiler team's needs, where we have a very static calendar and don't use invites, it works well for that, but I can appreciate that other teams have different needs. I'd encourage other teams and project members to use these calendars for events where it makes sense for them and to continue to use their previous solutions when it doesn't, until the project has a better solution for them. That's not ideal but it's the best that the current approach will be able to achieve. We can still use the README of this repository as a index of the project's calendars regardless of how they are managed.