Kalender-Plugin-Funktionen, um es für uns wirklich nützlich zu machen

Merkmal
1

Diskussion fortgesetzt von Discourse Calendar:

Das Fedora Project hat derzeit unsere eigene Kalender-Webanwendung, Fedocal. Sie ist reif für ein Update, und ich überlege, ob wir sie durch Kalender in Discourse ersetzen könnten, anstatt die eigenständige Anwendung neu zu schreiben. Dies ist keine Funktionsanfrage, sondern eine Erfassung unserer Anwendungsfälle und dessen, was meiner Meinung nach fehlt, während wir evaluieren, was zu tun ist.

Anwendungsfälle

Ich sehe drei wichtige Anwendungsfälle für Fedocal. Wenn es mehr gibt, lassen Sie es mich bitte wissen, und ich werde sie zur Berücksichtigung hinzufügen.

  1. Terminplanung. Dies ist bei weitem der wichtigste.
  2. Leuten die Möglichkeit geben, ihre Verfügbarkeit mitzuteilen. Derzeit bitten wir Personen mit Verantwortung im Projekt, dies für Urlaube einzutragen, aber nur wenige tun es tatsächlich. (Ich persönlich finde es einfach zu umständlich, wenn ich mich daran erinnere.)
  3. Anzeige von Fedora-Veranstaltungen wie Flock to Fedora, Week of Diversity oder Release Parties. Das tun wir heute eigentlich nicht.

Andere Möglichkeiten

  • Wir haben versucht, Fedocal für den Zeitplan der Flock-Konferenz im Jahr 2013 zu verwenden, aber seitdem nicht mehr. Es wäre nett, wenn wir eine Lösung hätten, die das attraktiv und einfach macht.
  • Anzeige des Fedora-Release-Zeitplans selbst. Derzeit glaube ich, dass wir dies nur zur Planung der Go/No-Go-Meetings verwenden, nicht tatsächlich für den Zeitplan. Wenn wir dies tun würden, müsste es automatisch von Fedora Project schedules importiert werden, anstatt manuell eingegeben zu werden.

Mängel des aktuellen Discourse Calendar Plugins

Das derzeit hinzugefügte “Events”-System ist für unsere Bedürfnisse falsch. (Es sammelt “Events” aus Beiträgen im gesamten Forum und fügt sie in einen einzigen globalen Kalender ein. Wir brauchen viel mehr als das.)

Meine erste Annahme ist, dass wir uns auf die Erweiterung des “traditionellen” Teils des Kalender-Plugins konzentrieren würden, das einen Kalender in der ersten Antwort auf ein Thema hat, das nur von Antworten auf dieses Thema “gespeist” wird. Es könnte jedoch möglich sein, dass der andere Ansatz – das Sammeln von Events im gesamten Forum – besser wäre. In diesem Fall müssten wir es jedoch erweitern, um mehrere Kalender anvisieren zu können. (Und in diesem Fall wäre es schön, sie in angeheftete Themen einbetten zu können, anstatt sie nur im Hamburger-Menü zu verstecken.)

Daher hier einige Dinge, die wir brauchen würden:

Im Allgemeinen

  1. Die Kalenderanzeige selbst ist ziemlich rudimentär.
    • Sie könnte viel schöner sein
    • Sie skaliert oder passt sich in keiner Weise an die Anzeige an
    • Sie ist fest auf EU-übliche Montag-Sonntag-Wochen eingestellt
    • Sie scheint immer Tage in UTC anzuzeigen, obwohl die Einträge in lokalen Zeitzonen sind, was dazu führt, dass ganztägige Ereignisse in einer lokalen Zeitzone auf dem Kalender zwei Tage umfassen können. (Das Discourse-Team ist sich dieses Fehlers bewusst.)
    • Die Monatsansicht zeigt derzeit nur die ersten paar Zeichen der Beschreibung eines Ereignisses. Das ist in Ordnung, wenn der Kalender nur um eine einfache Sache geht (siehe hier in Gebrauch für Fedora Social Hour), aber nicht gut für einen Kalender mit vielen verschiedenen Dingen.
    • Derzeit kann die “Feiertags”-Version des Kalenders Farben für Ereignisse zuweisen, tut dies jedoch mithilfe eines programmatisch abgeleiteten Werts vom Benutzernamen. Dies sollte stattdessen pro Ereignis konfigurierbar sein und für alle Kalender gelten, nicht nur für den Feiertagskalender.
  2. Ich glaube nicht, dass es einen .ical-Feed gibt? Das wäre schön, damit Leute ihn zu ihrem Google Kalender oder Ähnlichem hinzufügen können.
  3. Nice to have: Möglichkeit, Erinnerungs-E-Mails zu generieren, die an Mailinglisten gesendet werden, nicht nur an Abonnenten. Wir haben noch nicht alle auf Discourse!
  4. Nice to have: eine persönliche Kalenderansicht, in der man genau auswählt, welche Einträge verfolgt werden sollen.

Anwendungsfall Meetings

  1. Fedocal hat zwei primäre “Achsen” – die Gruppe, zu der der Kalendereintrag gehört (wie “Rat”), und der Ort (wie “#fedora-meeting”). Das Kalender-Plugin kann eines von beiden tun: Wir können ein Thema “Fedora Council Meetings” oder ein Thema “Fedora Meeting Channel” erstellen, aber die Einträge wären nicht verknüpft. Ich bin mir nicht wirklich sicher, wie das beste Design dafür als Plugin aussehen würde – ich denke, wir könnten etwas UX-Design-Expertise gebrauchen, um darüber nachzudenken.
    • Es wäre völlig in Ordnung, wenn die “Gruppen”-Achse Discourse-Gruppen wären, insbesondere weil wir irgendwann bald, ICH HOFFE Discourse-Gruppen mit unserem SSO verknüpfen werden.
    • Oder möglicherweise könnte die “Gruppen”-Achse des Kalenders ein Tag sein. Das wäre flexibler und würde für uns funktionieren, da wir eine Gruppen-zu-Tag-Zuordnung für unsere Website-Organisation planen.
    • Die “Orte”-Achse ist kurz – wir haben eine Handvoll Meeting-Kanäle, und es reicht wahrscheinlich aus, einen “anderen” Ort für seltene Fälle zuzulassen.
  2. Kritisch: Das System muss Konflikte auf beiden Achsen verhindern – oder zumindest davor warnen. Das heißt, es kann keine zwei Ratssitzungen zur gleichen Zeit geben, und es kann keine zwei Sitzungen von verschiedenen Gruppen am gleichen Ort zur gleichen Zeit geben.
    • außer wenn wir einen Sammelbegriff “andere” haben… also, ich schätze, einige Orte sollten Überlappungen zulassen.
  3. Die Syntax für wiederkehrende Ereignisse ist etwas seltsam, aber in Ordnung. Wiederkehrende Ereignisse werden jedoch nur als wiederkehrend im Kalendergitter angezeigt (und in der Erinnerung als aktualisiert auf das nächste), nichts weiter. Und es sollte mehr geben:
    • Kritisch: Es sollte möglich sein, dass Benutzer Benachrichtigungen für jedes wiederkehrende Ereignis abonnieren, und zwar pro Kalendereintrag.
      • Nice to have: eine Konfiguration pro Discourse-Gruppe für die Standardbenachrichtigungen für einen bestimmten Kalender, sodass z. B. Mitglieder der Ratsgruppe standardmäßig Benachrichtigungen für Ratskalendereinträge erhalten.
      • Nice to have: Möglichkeit, auch 15-minütige Warnbenachrichtigungen für bevorstehende Meetings zu konfigurieren.
    • Wichtig: Es sollte möglich sein, bestimmte Ereignisse als zu überspringend (oder zu einer anderen Zeit stattfindend) zu markieren, ohne das gesamte Ereignis zu ändern.
  4. Derzeit erfolgt die Ereignisdauer mit Einträgen wie [date=2021-11-28 time=12:00:00 timezone="America/New_York"] → [date=2021-11-28 time=13:00:00 timezone="America/New_York"]. Das ist mühsam einzugeben und das Ergebnis (2021-11-28T17:00:00Z → 2021-11-28T18:00:00Z) ist nicht sofort ersichtlich. Es wäre schön, stattdessen [date=2021-11-28 time=12:00:00 timezone="America/New_York" duration="1 hour"] zu haben.
    1. Nice to have: Einträge ohne Dauer sollten visuell unterschiedlich sein – und vielleicht nur für “ganztägige” Einträge erlaubt sein.
  5. Nice to have: Jeder Kalendereintrag (separat für wiederkehrende) könnte einen Link zu einem Thema für Agenda + Notizen haben. Dieses Thema würde nicht automatisch ohne Interaktion erstellt, sollte aber mit einem Klick einfach zu starten sein und nach der Erstellung automatisch verknüpft werden.

Anwendungsfall “Feiertage”

  1. Der Feiertagskalender sollte auch gruppenbewusst sein. Derzeit gibt es einige Sonderfälle für (Discourse-Site-)Mitarbeiter – das sollte verallgemeinert und konfigurierbar sein, und verschiedene Kalender sollten für verschiedene Gruppen sowie einen globalen Kalender zulässig sein.
  2. In seiner Standardkonfiguration zeigt der Feiertagskalender nationale Standardfeiertage für jede Person an, deren Gebietsschema konfiguriert ist. Wenn das mehr als, sagen wir, fünf Personen an nicht mehr als zwei verschiedenen Orten sind, überlagert dies alles andere. Discourse hat uns jedoch einen temporären Hack zur Verfügung gestellt, um dies zu verbergen.
  3. Nice to have: Derzeit erhalten Mitarbeiter ein :palm_tree: Emoji neben ihrem Benutzernamen, wenn sie im Urlaub sind, nur für andere Mitarbeiter sichtbar. Die Sichtbarkeit dieses Symbols sollte konfigurierbar sein.
  4. Nice to have: Konfiguration des anzuzeigenden Emojis zulassen.
    • Bonus nice to have: Benutzern ermöglichen, aus einer Liste von Emojis und Gründen für eine bestimmte Abwesenheitszeit (Urlaub, Krankheit, Reise usw.) auszuwählen.

Fedora Events

Eigentlich denke ich, dass das, was wir heute haben, dafür funktionieren könnte. Einige der oben genannten Punkte – schönere und flexiblere Kalenderanzeige, Benachrichtigungen, Farben – wären jedoch nützlich.

Für andere Möglichkeiten

  • Der Anwendungsfall für Konferenzpläne ist einfach der Anwendungsfall für Meeting-Pläne, aber sehr intensiv. Manuelle Konfliktverfolgung wird unmöglich. Hierfür könnte eine Achse auf Benutzerebene anstelle einer Achse auf Gruppenebene erforderlich sein. (Sprecher können nicht gleichzeitig an zwei Orten sein.) Und im Gegensatz zu unseren Meetingraum-Orten, die sich seit 15 Jahren kaum geändert haben (außer URL-Updates) und sich wahrscheinlich auch in den nächsten 15 Jahren nicht ändern werden, hat jedes Ereignis seine eigenen Orte.
  • Release-Zeitplan-Kalender: Ich denke, dies ist hauptsächlich eine Frage der Automatisierung beim Importieren aus den vorhandenen Zeitplandaten. Das bestehende Kalender-Plugin könnte größtenteils funktionieren, denke ich. Wie bei Fedora Events wären auch hier Farbcodes schön.
14 „Gefällt mir“
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 „Gefällt mir“
3

Herzlichen Glückwunsch, Angus!!! Das ist brillant. Dies hat das Potenzial, erheblich zu einer besseren Welt beizutragen (nicht nur zu einer Ansammlung von Foren, aber das ist auch cool). Mögen Sie es schaffen!

8 „Gefällt mir“
4

Hallo Angus,

Haben Sie hier Fortschritte gemacht? Es ist ein allgegenwärtiges Problem für alle meine Foren und treibt die Leute zu anderen Plattformen für Treffen und dergleichen.

2 „Gefällt mir“
5

Hallo Nathan, wir werden in etwa einem Monat einige Dinge zu teilen haben. In der Zwischenzeit können Sie mich privat unter coop.pavilion.tech erreichen und ich kann Ihnen helfen, Veranstaltungen in Ihrem Forum einzurichten.

Zusätzlich zum DEIP-Projekt denken wir darüber nach, das Events Plugin wiederzubeleben und es möglicherweise zu nutzen, um einige der oben genannten Bedenken auszuräumen.

4 „Gefällt mir“
6

Wie versprochen, hier ist der vollständige Bericht über Phase 1 des Projekts „Discourse Events Integration Plugin“.

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

Und hier ist die Prototyp-Implementierung des Event-Datenmodells (ein Ruby-Gem). Beachten Sie, dass sich der Gem in der Entwicklung befindet und noch nicht für den Produktionseinsatz bereit ist.

https://github.com/paviliondev/omnievent

Wie Sie dem Forschungsbericht entnehmen werden, wird das Plugin selbst in Phase 2 des Projekts erstellt.

4 „Gefällt mir“
7

Das ist beeindruckende Arbeit, Angus. Ich freue mich darauf, in der nächsten Zeit die Früchte zu sehen!

Ich bin fasziniert davon, wie viele Parallelen es zu meinem Fachgebiet der Gesundheitsinformatik gibt. Wir leiden unter denselben Problemen von mehreren organisch gewachsenen proprietären Datenmodellen, die nicht gut zusammenspielen. Und die Patienten leiden als Ergebnis.

Es gibt ein beeindruckendes Open-Data-Projekt, das im Wesentlichen dasselbe für alle Gesundheitsdaten tun will:

2 „Gefällt mir“
8

Nur eine weitere Aktualisierung, um zu vermerken, dass unsere Arbeit in Phase 1 von DAPSI positiv bewertet wurde und dieses Projekt in Phase 2 übergeht, d. h. den Bau des Events Integration Plugins. Ein Teil davon wird eine Überarbeitung des Pavilion Events Plugins beinhalten.

In der Tat. Ich hatte ein gutes Gespräch mit @pacharanero über diese Überschneidung beim Mittagessen in York.

5 „Gefällt mir“
9

Nur eine letzte Anmerkung hierzu: Die Beta-Version des Events Integration Plugins ist jetzt verfügbar :slight_smile:

Weitere Updates werde ich in diesem Thema posten.

5 „Gefällt mir“