The Grumpy Troll

Ramblings of a grumpy troll.

Calendar event scheduling

In discussion with nomad, over the topic of https://lopsa.org/content/calendars-we-dont-need-no-steeken-calendars, I noted that the core problem is the absence of a standard for exchange of data about calendar availability.

Various Calendar implementations, such as Google's, let you choose who to share calendar content with, including just free/busy, but that only works if the other attendees all use that same implementation.  Google Calendar also lets you find a time suitable for all attendees, if they're using Google Calendar.  Again, this only works if all attendees use Google's product.  [Disclosure: I used to be an SRE for the Google Calendar team].

The IETF knows about this problem and is working on CalDAV Scheduling Extensions to WebDAV, currently in last call.  Among the extensions it provides are CALDAV:schedule-deliver-invite and CALDAV:schedule-query-freebusy.

The core problem is that if you want to be able to share availability with a vendor or business partner, you don't want to have to approve access individually, repeatedly, but you don't want your availability information visible to spammers.

What I realised and proposed (refined here) during the discussion is that the default state for a meeting, as opposed to a general event, should be to be created “unscheduled”.  The proto-meeting would at most include a rough day/time-window and data about proposed recurrence rules.  Each proposed attendee then indicates if they will attend, and then if they will attend then their availability information will be shared.

At this point, you still have to approve access, but the act of approving is the same as indicating attendance.  Moreover, what is created here is a feedback loop to help adjust the behaviour of the person creating the proto-meeting.  Nature loves feedback loops and the absence of such is normally a sign of an artificial system doomed to failure and/or abuse.

If your event is just placed onto someone's calendar when you create it and they have to agree to attend, then that person might not be scrupulous about going through and replying "yes" for each meeting.  My past experience is that many folks just show up, while never replying to indicate attendance.  Then you have folks who never attend meetings they didn't reply to, reasoning that "you invited me does not compel me to attend".  The meeting creator can't tell the difference.

Switch to a system where folks have to reply yes before you can even schedule the meeting onto their calendar.  The creator can now tell the difference.  They only need to find a time suitable for a subset of original invitees.  Further, they can rapidly learn what sorts of behaviour on their part make it more likely for folks to agree to attend.  I posit that this would lead to better event descriptions, more agendas, shorter meetings and smaller meetings, so fewer folks slowing everything down.

[There are other additional possibilities relating to using a public karma scoring system, but that's not the main point of this post]

The response "yes" would carry an authorization token tied explicitly to the event id of the proto-meeting.

Use of this system does not preclude sharing free/busy with an account as a more open form of scheduling.  The system interoperates with existing practices to the extent that a calendar can be set to “require that I approve a meeting proposal before the meeting can be scheduled on my calendar” setting, plus “the only event type others can add to my calendar is meeting”.  Existing implementations would only add support for this at the same time as others gain the ability to create proto-meetings, so there's no window of reduced interoperability.

-The Grumpy Troll

Comments

rogerbw
I think it's a good start. Automatically allocating a meeting time would combine scheduling with privacy (A doesn't learn anything about B's schedule except that this particular slot was free). I think I'd do this at the point where enough people have replied that there's only one common slot available (or, if necessary, back up to before the last reply and use a randomly-selected one of those slots); this encourages people to get in early.

(This could also be combined with a room-booking system - when you have only one combination of time and large-enough-room available, nail down the meeting at that point.)

I'm a great fan of iCal, but I've invented several layers of my own on top of it precisely because the existing ones seem to be tied to a corporate-hierarchical form where Boss can force Peon to go to a meeting without Peon having any say in the matter.
Categories: calendaring caldav