Group Calendaring Discovery Phase

Introduction

In order to facilitate participation and scheduling of group meetings, W3C Groups have requested for a long time the possibility to manage calendars of events, subscribe to them as well as easily view them on the Web.

A full set of requirements was produced and we started evaluating candidate solutions, third-party or home-made.

The set of requirements for the initial version can be summarized as follows:

• Group Chairs and Team Contacts need to be able to easily create and edit group meetings
• Recurring meetings need to be managed, for example to allow entering weekly group meetings in the system
• Possibility to associate a meeting to a group, and invite other groups
• Possibility to invite additional individuals
• Possibility to provide links to agenda, minutes and attendance instructions to meeting participants
• View group meetings on the W3C Website
• Synchronize calendars to a local calendaring client

Off-the-shelf tools

At first, it might seem like a good idea to use a third-party service as many calendaring solutions already exist, backed by several standards such as CalDAV and iCalendar. That's why we first tested this possibility. For this, we evaluated two different services:

• Nextcloud
• SOGo

We excluded Google Agenda as we cannot guarantee it would work from all countries.

They are both open source solutions and are fairly similar in their calendaring capabilities as they both implement the CalDAV protocol and provide easy to use UIs to create and edit events, in addition to supporting editing from local clients such as Thunderbird or Calendar on Mac.

Additionally, by design, they both provide support for recurring meetings, invitations and public sharing of calendars.

Finally, Nextcloud has a feature that allows embedding calendars in external web pages, which would make integration into W3C Web site super easy, with the caveat of a visual integration that would be hard to customize, and potential accessibility issues.

Difficulties arose when we tried integrating them with our groups. While they both allow calendars to be shared with groups, they do it differently and in ways that may be difficult to keep in sync when for example a user joins or leaves a group. Also, only SOGo allowed to invite other groups to meetings, but in a very static way, expanding the group into the list of its participants and inviting them one by one, at the time of creation. Again, if a user were to join or leave the group, they wouldn't be added or removed from the event's list of invitees. So we would have to develop scripts to ensure they stay synchronized.

Regarding the possibility to add links to agenda, minutes and other information, this is very much possible, but not in a structured and exploitable way. Indeed, those could simply be added as part of a meeting's description, or even as meeting links, but how would we then be able to retrieve that information so we could for example create a list of a group's minutes. We could ask meeting organizers to follow a specific format, but without any ways to enforce it, mistakes are going to happen, which could in the worst case lead to sensitive information being publicly leaked. Yes, iCalendar allows defining custom properties, but no clients (be them web-based or local) seem to display nor allow editing them, thus making that possibility unusable in practice.

CalDAV servers also only support access permissions at the event scale, so for example we couldn't say that the meeting attendance instructions (which could contain sensitive information such as a meeting password) are restricted to the people invited to the event and group participants.

Last but not least, we are afraid of some potential privacy issues with those tools, from what we believe to be a limitation of the iCalendar protocol: when you invite a person to a meeting, the publicly subscribable calendar will contain the name and email address of that person. Privacy-wise this is very bad, and very likely to be common to any CalDAV server that exists. Preventing that would again mean fixing those tools, which could be difficult as this is at the core of the CalDAV/iCalendar invitation mechanism.

Home-made prototyping

So, after these initial tests, it appeared that although off-the-shelf solutions are very appealing, we would still need to create a lot of tools and workarounds to make the data safe, reliable and reusable, which would likely take even longer to implement than starting from scratch with only the set of features we need. For those reasons we decided to make some basic prototyping of what could be a home-made solution.

The main idea is to provide chairs and team contact with a form to create and edit events specifically tailored to our needs and save them in our own database.

Prototype of a meeting creation form

For each group we can then display related events on the website (most likely below https://www.w3.org/groups) with the possibility to export them as subscribable iCal files.

Prototype of a group calendar view

Making our own form allows us to easily integrate with the rest of our database (groups, users, ...) and filter the information to display to users depending on their access rights. Exporting those to iCal is also fairly easy and we can format it the way we want while ensuring no personal data gets publicly accessible.

When creating or editing events we also have the possibility to notify participants by email so that they can easily add them to their own calendars.

Recurring meetings are a bit trickier, but not impossible by any means. A simple solution may be to create all occurrences as independent events so that they can then easily be edited. Editing all occurrences at once becomes harder though, so this may not be the best solution. We will see how best to handle them as the project progresses.

A downside of creating our own system is that people won't be able to use their local client to add or edit events. But as we've discussed earlier, allowing alternative clients to do so also comes with its own limitations, even more so when implementations of the CalDAV protocol varies so greatly among them. That would likely become a nightmare for user support, while proposing a single interface to create meetings makes that much simpler.

Conclusion

As we have seen, providing group calendaring is not as easy as it seems at first glance. Although we try to avoid reinventing the wheel as much as we can, third-party calendaring services come with a number of limitations that may be very difficult to overcome, while creating our own isn't that scary and would provide better flexibility and integration with the rest of our tool chain. We believe this is the right path and will be working on this solution in the upcoming weeks. We expect to release a minimal viable product by January 2021.

calendar2