Calendar plugin features to make it really useful for us

Feature
1

Continuing the discussion from Discourse Calendar:

The Fedora Project currently has our own calendaring web app, Fedocal. It’s due for an update, and I’m thinking about whether we could replace it calendars on Discourse rather than rewriting the stand-alone app. This isn’t a feature request really, but rather a capturing of our use cases and what I see as missing as we evaluate what to do.

Use cases

There are three important use cases I can see for Fedocal. If there are more, please let me know and I’ll add them to consideration.

  1. Scheduling meetings. This is by far the most important.
  2. Letting people share their availability. Currently we request that people with responsibility in the project enter this for vacations, but few people actually do it. (I, personally, find it just too cumbersome when I do remember.)
  3. Showing Fedora events like Flock to Fedora, Week of Diversity, or Release Parties. We don’t actually do this today.

Other possibilities

  • We tried to use Fedocal for the Flock conference schedule in 2013, but haven’t done that since. It’d be nice if we had a solution which made that appealing and easy.
  • Showing the Fedora release schedule itself. Currently, I think we only use this to schedule the go/no-go meetings, not actually the schedule. If we would do this, it needs to come automatically from Fedora Project schedules rather than needing manual entry.

Shortcomings of current Discourse Calendar plugin

The “events” system being added to it is currently wrong for what we need. (It collects “events” from posts across the whole site and puts them on one single global calendar. We need way more than that.

My first assumption is that we’d focus on extending the “traditional” part of the calendar plugin, which has a calendar in the first reply to a topic which is “fed” by replies to that topic alone. However, it could be possible that the other approach — grabbing events across the site — would be better. In that case, though, we’d need to extend it to be able to have multiple calendars to target. (And in that case it’d be nice to be able to embed them in pinned topics, not just be hidden in the hamburger menu.)

So, that said, here’s some things we’d need:

In general

  1. The calendar display itself is pretty rudimentary.
    • It could be a lot prettier
    • It doesn’t scale or adapt to how it’s being displayed in any way
    • It is hard-coded to EU-style Monday-Sunday weeks
    • It seems to always show days in UTC, even though the entries are in local timezones, making it so day-long events in a local timezone can look like they span two days on the calendar. (The Discourse team is aware of this bug.)
    • The month-view currently only shows the first few characters of an event’s description. That’s fine if the calendar is just about one simple thing (see in use here for Fedora Social Hour, but not good for a calendar with a lot of different things.
    • Currently, the “Holiday” version of the calendar can assign colors to events, but it does so using a value programatically derived from the username. This should instead be configurable on a per-event basis, and apply to all calendars not just the holiday one.
  2. I don’t think there’s an .ical feed? That’d be nice for people to be able to add to their Google Calendar or whatever.
  3. Nice to have: ability to generate reminder mails sent to mailing lists, not just subscribed users. We don’t have everyone on Discourse yet!
  4. Nice to have: a personal calendar view where you opt in to exactly what entries to track.

Meetings use case

  1. Fedocal has two primary “axes” — the group that the calendar entry belongs to (like “council”) and the location (like “#fedora-meeting”). The calendar plugin can do one or the other: we can make a “Fedora Council Meetings” topic or a “Fedora Meeting Channel” topic, but entries wouldn’t be linked. I’m not really sure what the best design for that as a plugin would look like — I think we could use some UX designer expertise in thinking about that.
    • it would be just fine if the “group” axis is Discourse groups, especially because we’re SOMEDAY SOON I HOPE going to get Discourse groups linked to our SSO.
    • or, possibly, the calendar “group” axis could be a tag. That might be more flexible, and would work for us because we’re planning on a group-to-tag mapping for our site organization.
    • the “locations” axis is short — we have a handful of meeting channels, and it’s probably sufficient to allow an “other” location for odd cases.
  2. Critical: The system needs to prevent – or at least warn on – conflicts on both axis. That is, there can’t be two council-group meetings at the same time, and there can’t be two meetings from a different group in the same location at the same time.
    • except if we have a catch-all “other”… so, I guess some locations should be able to have overlaps.
  3. The syntax for repeating events is kind of weird, but okay. However, repeating events just show up in the calendar grid as repeating (and in the reminder as updated to the next one), not anything more. And there should be more:
    • Critical: It should be possible for users subscribe to a notification for each repeating event, on a per calendar-entry basis.
      • Nice to have: a per-Discourse-group configuration for the default notifications for a particular calendar, so e.g. members of the council group default to getting notifications for council calendar entries.
      • Nice to have: ability to also configure 15-minute warning notifications for upcoming meetings
    • Important: It should be possible to mark specific event as to be skipped (or to be held at a different time) without changing the whole thing
  4. Right now, event duration is done with entries like [date=2021-11-28 time=12:00:00 timezone="America/New_York"] → [date=2021-11-28 time=13:00:00 timezone="America/New_York"]. That’s tedious to enter and the result (2021-11-28T17:00:00Z → 2021-11-28T18:00:00Z) not immediately obvious. It’d be nice to have [date=2021-11-28 time=12:00:00 timezone="America/New_York" duration="1 hour"] instead.
    1. Nice to have: Entries without duration should be visually different — and perhaps only allowed for “whole day” entries.
  5. Nice to have: each calendar entry (separately for repeating ones) could have a link to an agenda + notes topic. This topic would not be automatically created without interaction, but should be easy to start with one click, and once created, linked automatically.

“Holidays” use case

  1. The holiday calendar should also be group aware. Right now it has some special-casing for (Discourse site) Staff — that should be generalized and configurable, and different calendars allowed for different groups as well as a global one.
  2. In its default config, the holiday calendar shows standard national holidays for every person who has their locale configured. If that’s more than, like, five people in no more than two different locations, it overwhelms all else. Discourse has provided us with a temporary hack to hide that, though.
  3. Nice to have: Right now staff members get a :palm_tree: emoji next to their username when they’re on vacation, only visible to other staff members. The visibility of this icon should be configurable.
  4. Nice to have: allow configuration of which emoji is shown.
    • Bonus nice to have: allow users to select from a list of emojis and reasons for a given unavailable time (vacation, sick, travel, etc.)

Fedora Events

Actually, I think what we have today could work for this. However, some of the above — prettier and more flexible calendar display, notifications, colors — would be useful.

For other possibilities

  • Conference schedule use case is just the meeting schedule use case, but very intensely so. Manually keeping track of conflicts becomes impossible. For this, may need user-level axis instead of group-level axis. (Speakers can’t be in two places at once.) And unlike our meeting room locations, which haven’t changed much in 15 years (except for URL updates) and probably won’t in another 15, each event has its own set of locations.
  • Release schedule calendar: I think this is mostly a matter of automation in importing from the existing schedule data. Existing calendar plugin could mostly work, I think. Again as with Fedora Events, color coding would be nice.
14 Likes
2

Pavilion is working on a Discourse Events Integration Plugin (DEIP), which, inter alia, will allow you to publish events to Discourse from other services and platforms. We submitted a proposal to DAPSI (an EU NGI program), which was accepted for funding. The program just kicked off (last night) and we’re starting work on it. This will overlap with some of the points you raised.

Edited version of the executive summary from the proposal

There is no abstract data model for calendar events in regular use by online event services. We will first specify and prototype a working data model based on an assimilation of previous standardisation attempts and the data models of popular event services (“DEIP Specification and Prototype”). We will then productize this specification in the form of an open source Discourse plugin that will allow online communities to easily transfer calendar event data between popular event management platforms (initially Eventbrite, Meetup and Zoom) and Discourse, the most popular open source community software (“DEIP Product”). We will be offering service-orientated subscriptions to businesses using the MVP to ensure the plugin’s continued viability over time.

The DEIP Product will be a commercially-viable open-source alternative to Facebook’s recently-launched Official Events API, which provides similar functionality, but for Facebook’s “walled garden” of community data. Facebook has been investing in its community features for some time, and that investment is growing. Facebook’s continued focus on this aspect of its product means open-source alternatives need to be continually improving equivalent offerings to stay viable. The DEIP Specification and Product will be vital tools in that struggle.

Discourse is one of the few truly viable open source platforms for online communities. It’s the most popular community project on github, and recently raised $20 Million USD to further grow its expanding organisation (55 employees supporting over 32,000 communities). Discourse’s platform is 100% open source and is deeply embedded in open source software communities and culture.

Pavilion (the Applicant) is a co-operative of developers and product managers and an official partner of Discourse. We’ve been working with Discourse for over 6 years and have built a substantial portion of the extant 3rd-party plugins for Discourse, including the most popular Discourse plugin and a number of plugins which have subsequently been adopted (made “official”) by Discourse.org.

The combined Specification and Product will serve as both an exponent of calendar event data model standardisation, and provide an efficient open-source solution for event management on the tens of thousands of online communities using Discourse.

Summary (Problem and Solution)

The primary problem faced by online communities managing events is service integration. Communities use a mixture of marketing platforms such as Eventbrite, discovery platforms such as meetup.com, meeting tools such as Zoom, or all-in-one solutions such as Facebook. The difficulty of managing a community across multiple services means there is an incentive to use proprietary solutions which offer convenience over transparency and portability.

The DEIP will be both a calendar event data model specification and prototype, and an open-source commercially-viable Discourse plugin. In summary, the DEIP will:

  1. Define a practical calendar event data model specification.
  2. Implement the specification in a working prototype.
  3. Develop the prototype into a Discourse Plugin with support for importing from popular event services, and exporting using common calendaring standards.
  4. Release the plugin as an open source product, with a subscription service targeted at business users.

Specification (The Research Component)

The main standards in the management of calendar events are RFC 5545 (.ics format) and RFC 4791 (CalDAV, or “ical feeds”). The problem with these standards is that they are not currently used to model calendar event data available from modern APIs. The equivalent objects available via the Eventbrite, Meetup and Zoom APIs do not translate to RFC 5545, or to each other. Attempts by industry bodies to develop an Abstract Calendaring API have yet to bear fruit, despite some recent attempts. Moreover, proprietary services do not provide group/site/community-wide CalDAV feeds (they sometimes provide user-specific feeds). In short, there is a significant paucity of calendar event data model standardisation.

The primary research component of the DEIP will be to specify an abstract event data model that implements the existing standardization attempts, while maintaining practical usability vis-a-vis the most popular proprietary event-related services (the “DEIP Specification”). This specification will then be converted into a working prototype (initially in Ruby; subsequently in other languages), allowing for the creation, reading, update and deletion of generic calendar events (the “DEIP Prototype”). Depending on the outcomes of this work, we may seek to package the DEIP Prototype for distribution via different package systems, e.g. ruby gems.

As well as forming the basis of the MVP (see below), the specification and prototype will be published on the DEIP landing page with accompanying explanations of the thinking behind it. We will also dedicate a section of our own community to it for further discussion. We want to be an active part of efforts to bring event software services closer to the use of standard data models to improve service interoperability and portability.

Development (The Development Component)

We will develop the DEIP Specification and Prototype into an MVP Discourse Plugin offering the following features:

  • Discourse Event API with Create, Read and Delete support. Update support (i.e. two-way communication) will be added in a later product version.
  • Specific support for popular services. Initially Eventbrite, Meetup and Zoom.
  • Integration with the Discourse Event Plugin to display events within Discourse topics and provide an Events Calendar within Discourse itself.
  • A CalDAV server to provide a unified feed of all events in a community, with the ability to filter by category and user.
  • Integration with the Legal Tools Plugin for GDPR support and the Locations Plugin for GeoJSON location mapping using open source mapping solutions.

Deployment (Relevance, impact and benefits)

Pavilion supports thousands of online communities through our paid consulting work and unpaid open source work, many of which have evinced a clear need for the DEIP Product, including university researchers, health support communities, hobbists, small businesses, neighbourhoods, startups, non-profits, Fortune-500 companies, fantasy novelists and nature photography enthusiasts. For a sampling of this need, see here, here, here, here, here, here and here. The lack of ease of event portability and integration is frequently a key factor in the choice between locked-in proprietary solutions like Facebook and open source solutions like Discourse.

Pavilion members will be personally deploying the DEIP Product for our existing clients who run events, as well as assisting the many open source users of our work, like those linked above. In addition to Pavilion’s work within the Discourse community, the DEIP will have:

Our goal is for the DEIP Product to be a viable alternative to event management on proprietary community platforms and for the DEIP Specification and Prototype to advance efforts in calendar event data model standardisation.

Business Model (Commercial Exploitation)

Pavilion has developed a subscription model for our open source Discourse plugins that maintains our commitments to open source and supporting non-profit communities, while ensuring our members get properly compensated for their work. The model has the following features

  • 100% open source code.
  • Selected “business” features that are not visible on the application client unless the community manager has purchased a subscription.
  • Free subscriptions for non-profit communities that use the “business” features.
  • Business-orientated services for paid subscribers.

Feature-restriction in a 100% open source code base can be programmatically overcome, however this is not relevant to the target market for paid subscriptions. Businesses want to pay for services that benefit them, and those that choose to overcome the restrictions are not the target customers for that aspect of the product.

We could potentially expand the scope of this project to include some of the other things you’ve mentioned, i.e. those focused on event features within Discourse itself, however we’d need additional funding. If you want to discuss this further you can PM me about it. In any event, I’ll be sharing more details about the DEIP project here on meta as we progress.

10 Likes
3

Congratulations, Angus!!! That is brilliant. This has the potential to contribute significantly to a better world (not just a bunch of Forums, but that is cool too). May you pull it off!

8 Likes
4

Hi Angus,

Have you made any progress with this? It is an ever present problem for all of my forums, and which drives folk to other platforms for meetings and the like.

2 Likes
5

Hey Nathan, we’ll have some things to share in about a months time. In the meantime you can reach out to me privately on coop.pavilion.tech and I can help you setup events on your forum.

In addition to the DEIP project we’re thinking of reviving the Events Plugin and may use it to address some of the concerns mentioned above.

4 Likes
6

As promised, here’s the full report on Phase 1 of the Discourse Events Integration Plugin project.

https://docs.google.com/document/d/1-oJsXivT_KRBZ-wUQ-TbHdO7Z-qf7z4GeiRiJ014V-E/edit?usp=sharing

And here’s the prototype implementation of the event data model (a ruby gem). Note that the gem is in development and not ready for production use.

As you’ll pick up reading the research report, the plugin itself will be built in Phase 2 of the project.

4 Likes
7

That is impressive work, Angus. I look forward to seeing the fruit over the next wee while!

I’m intrigued by how many parallels there are with my field of health informatics. We suffer the same problems of multiple organically grown proprietary data models which don’t play nicely. And patients suffer as a result.

There is an impressive open data project which essentially seeks to do the same for all health data:

2 Likes
8

Just another update to note that our work in Phase 1 was favourably reviewed by DAPSI and this project is progressing to Phase 2, i.e. the construction of the Events Integration Plugin. Part of this will involve a revamp of the Pavilion Events Plugin.

Indeed. I had a good chat with @pacharanero about this overlap over lunch in York.

5 Likes
9

Just a final note here that the beta version of the Events Integration Plugin is now available :slight_smile:

I’ll post further updates in that topic.

5 Likes