Fonctionnalités du plugin Calendrier pour le rendre vraiment utile pour nous

Poursuivant la discussion à partir de Calendrier Discourse :

Le projet Fedora dispose actuellement de notre propre application web de calendrier, Fedocal. Elle est due pour une mise à jour, et je réfléchis à la possibilité de remplacer les calendriers sur Discourse plutôt que de réécrire l’application autonome. Il ne s’agit pas vraiment d’une demande de fonctionnalité, mais plutôt d’une description de nos cas d’utilisation et de ce qui, selon moi, manque alors que nous évaluons quoi faire.

Cas d’utilisation

Je vois trois cas d’utilisation importants pour Fedocal. S’il y en a d’autres, veuillez me le faire savoir et je les ajouterai à la considération.

  1. Planification des réunions. C’est de loin le plus important.
  2. Permettre aux gens de partager leur disponibilité. Actuellement, nous demandons aux personnes responsables du projet de saisir ces informations pour les vacances, mais peu de gens le font réellement. (Personnellement, je trouve cela trop fastidieux, même quand je m’en souviens.)
  3. Affichage des événements Fedora comme Flock to Fedora, Semaine de la diversité ou Fêtes de publication. Nous ne le faisons pas actuellement.

Autres possibilités

  • Nous avons essayé d’utiliser Fedocal pour le calendrier de la conférence Flock en 2013, mais nous ne l’avons pas fait depuis. Ce serait bien si nous avions une solution qui rendait cela attrayant et facile.
  • Affichage du calendrier de publication de Fedora lui-même. Actuellement, je pense que nous l’utilisons uniquement pour planifier les réunions de décision, pas le calendrier lui-même. Si nous le faisions, il faudrait qu’il provienne automatiquement de Fedora Project schedules plutôt que d’une saisie manuelle.

Lacunes du plugin Calendrier Discourse actuel

Le système d’“événements” qui y est ajouté est actuellement incorrect pour nos besoins. (Il collecte des “événements” à partir de publications sur l’ensemble du site et les place sur un seul calendrier global. Nous avons besoin de beaucoup plus que cela.

Ma première hypothèse est que nous nous concentrerions sur l’extension de la partie “traditionnelle” du plugin calendrier, qui a un calendrier dans la première réponse à un sujet qui est “alimenté” par les réponses à ce sujet uniquement. Cependant, il est possible que l’autre approche — récupérer les événements sur le site — soit meilleure. Dans ce cas, cependant, nous devrions l’étendre pour pouvoir avoir plusieurs calendriers cibles. (Et dans ce cas, il serait bien de pouvoir les intégrer dans des sujets épinglés, pas seulement les cacher dans le menu hamburger.)

Cela dit, voici quelques éléments dont nous aurions besoin :

En général

  1. L’affichage du calendrier lui-même est assez rudimentaire.
    • Il pourrait être beaucoup plus joli
    • Il ne s’adapte pas ou ne s’adapte pas à la façon dont il est affiché de quelque manière que ce soit
    • Il est codé en dur pour les semaines du lundi au dimanche de style européen
    • Il semble toujours afficher les jours en UTC, même si les entrées sont dans des fuseaux horaires locaux, ce qui fait que les événements d’une journée dans un fuseau horaire local peuvent sembler s’étendre sur deux jours sur le calendrier. (L’équipe Discourse est au courant de ce bug.)
    • La vue mensuelle n’affiche actuellement que les quelques premiers caractères de la description d’un événement. C’est bien si le calendrier ne concerne qu’une seule chose simple (voir en utilisation ici pour Fedora Social Hour, mais pas bon pour un calendrier avec beaucoup de choses différentes.
    • Actuellement, la version “Vacances” du calendrier peut attribuer des couleurs aux événements, mais elle le fait en utilisant une valeur dérivée programmatiquement du nom d’utilisateur. Cela devrait plutôt être configurable par événement, et s’appliquer à tous les calendriers, pas seulement à celui des vacances.
  2. Je ne pense pas qu’il y ait de flux .ical ? Ce serait bien que les gens puissent l’ajouter à leur Google Agenda ou autre.
  3. Agréable à avoir : possibilité de générer des e-mails de rappel envoyés aux listes de diffusion, pas seulement aux utilisateurs abonnés. Nous n’avons pas encore tout le monde sur Discourse !
  4. Agréable à avoir : une vue de calendrier personnelle où vous choisissez exactement quelles entrées suivre.

Cas d’utilisation des réunions

  1. Fedocal a deux “axes” principaux — le groupe auquel appartient l’entrée du calendrier (comme “conseil”) et l’emplacement (comme “#fedora-meeting”). Le plugin calendrier peut faire l’un ou l’autre : nous pouvons créer un sujet “Réunions du Conseil Fedora” ou un sujet “Canal de réunion Fedora”, mais les entrées ne seraient pas liées. Je ne suis pas vraiment sûr de ce à quoi ressemblerait la meilleure conception pour cela en tant que plugin — je pense que nous pourrions utiliser l’expertise d’un concepteur UX pour y réfléchir.
    • ce serait très bien si l’axe “groupe” était des groupes Discourse, surtout parce que nous allons un jour bientôt J’ESPERE lier les groupes Discourse à notre SSO.
    • ou, éventuellement, l’axe “groupe” du calendrier pourrait être une étiquette. Cela pourrait être plus flexible, et cela nous conviendrait car nous prévoyons un mappage groupe-étiquette pour l’organisation de notre site.
    • l’axe “emplacements” est court — nous avons une poignée de canaux de réunion, et il est probablement suffisant de permettre un emplacement “autre” pour les cas particuliers.
  2. Critique : Le système doit empêcher — ou du moins avertir sur — les conflits sur les deux axes. C’est-à-dire qu’il ne peut pas y avoir deux réunions de groupe du conseil en même temps, et il ne peut pas y avoir deux réunions d’un groupe différent dans le même emplacement en même temps.
    • sauf si nous avons un “autre” fourre-tout… donc, je suppose que certains emplacements devraient pouvoir avoir des chevauchements.
  3. La syntaxe des événements récurrents est un peu étrange, mais acceptable. Cependant, les événements récurrents apparaissent simplement dans la grille du calendrier comme récurrents (et dans le rappel comme mis à jour vers le suivant), rien de plus. Et il devrait y avoir plus :
    • Critique : Il devrait être possible pour les utilisateurs de s’abonner à une notification pour chaque événement récurrent, par entrée de calendrier.
      • Agréable à avoir : une configuration par groupe Discourse pour les notifications par défaut d’un calendrier particulier, de sorte que, par exemple, les membres du groupe du conseil reçoivent par défaut des notifications pour les entrées du calendrier du conseil.
      • Agréable à avoir : possibilité de configurer également des notifications d’avertissement de 15 minutes pour les réunions à venir.
    • Important : Il devrait être possible de marquer un événement spécifique comme à ignorer (ou à tenir à un autre moment) sans changer l’ensemble.
  4. Actuellement, la durée de l’événement est gérée avec des entrées comme [date=2021-11-28 time=12:00:00 timezone="America/New_York"] → [date=2021-11-28 time=13:00:00 timezone="America/New_York"]. C’est fastidieux à saisir et le résultat (2021-11-28T17:00:00Z2021-11-28T18:00:00Z) n’est pas immédiatement évident. Il serait agréable d’avoir [date=2021-11-28 time=12:00:00 timezone="America/New_York" duration="1 hour"] à la place.
    1. Agréable à avoir : Les entrées sans durée devraient être visuellement différentes — et peut-être uniquement autorisées pour les entrées “journée entière”.
  5. Agréable à avoir : chaque entrée de calendrier (séparément pour les récurrentes) pourrait avoir un lien vers un sujet d’ordre du jour + notes. Ce sujet ne serait pas créé automatiquement sans interaction, mais devrait être facile à démarrer en un clic, et une fois créé, lié automatiquement.

Cas d’utilisation “Vacances”

  1. Le calendrier des vacances devrait également être conscient des groupes. Actuellement, il a une mise en forme spéciale pour le personnel (du site Discourse) — cela devrait être généralisé et configurable, et différents calendriers autorisés pour différents groupes ainsi qu’un calendrier global.
  2. Dans sa configuration par défaut, le calendrier des vacances affiche les jours fériés nationaux pour chaque personne ayant sa locale configurée. Si cela concerne plus de, disons, cinq personnes dans pas plus de deux endroits différents, cela submerge tout le reste. Discourse nous a fourni un correctif temporaire pour masquer cela, cependant.
  3. Agréable à avoir : Actuellement, les membres du personnel reçoivent un emoji :palm_tree: à côté de leur nom d’utilisateur lorsqu’ils sont en vacances, visible uniquement par les autres membres du personnel. La visibilité de cette icône devrait être configurable.
  4. Agréable à avoir : permettre la configuration de l’emoji affiché.
    • Bonus agréable à avoir : permettre aux utilisateurs de choisir parmi une liste d’emojis et de raisons pour une période d’indisponibilité donnée (vacances, maladie, voyage, etc.)

Événements Fedora

En fait, je pense que ce que nous avons aujourd’hui pourrait fonctionner pour cela. Cependant, certains des éléments ci-dessus — affichage du calendrier plus joli et plus flexible, notifications, couleurs — seraient utiles.

Pour d’autres possibilités

  • Le cas d’utilisation du calendrier de conférence n’est que le cas d’utilisation du calendrier des réunions, mais de manière très intense. Le suivi manuel des conflits devient impossible. Pour cela, il pourrait être nécessaire d’avoir un axe au niveau de l’utilisateur plutôt qu’au niveau du groupe. (Les intervenants ne peuvent pas être à deux endroits à la fois.) Et contrairement à nos salles de réunion, qui n’ont pas beaucoup changé depuis 15 ans (sauf mises à jour d’URL) et ne changeront probablement pas dans les 15 prochaines années, chaque événement a son propre ensemble d’emplacements.
  • Calendrier du calendrier de publication : Je pense que cela relève principalement de l’automatisation de l’importation des données existantes du calendrier. Le plugin calendrier existant pourrait largement fonctionner, je pense. Encore une fois, comme pour les événements Fedora, le codage couleur serait agréable.
14 « J'aime »

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 « J'aime »

Félicitations, Angus!!! C’est génial. Cela a le potentiel de contribuer de manière significative à un monde meilleur (pas seulement à un tas de forums, mais c’est cool aussi). Puisse tu y parvenir !

8 « J'aime »

Bonjour Angus,

Avez-vous fait des progrès à ce sujet ? C’est un problème constant pour tous mes forums, et qui pousse les gens vers d’autres plateformes pour des réunions et autres.

2 « J'aime »

Salut Nathan, nous aurons des choses à partager dans environ un mois. En attendant, vous pouvez me contacter en privé sur coop.pavilion.tech et je pourrai vous aider à organiser des événements sur votre forum.

En plus du projet DEIP, nous envisageons de relancer le plugin d’événements et pourrions l’utiliser pour répondre à certaines des préoccupations mentionnées ci-dessus.

4 « J'aime »

Comme promis, voici le rapport complet sur la phase 1 du projet de plugin d’intégration des événements Discourse.

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

Et voici l’implémentation prototype du modèle de données d’événements (un gem Ruby). Notez que le gem est en cours de développement et n’est pas prêt pour une utilisation en production.

https://github.com/paviliondev/omnievent

Comme vous le constaterez en lisant le rapport de recherche, le plugin lui-même sera construit dans la phase 2 du projet.

4 « J'aime »

C’est un travail impressionnant, Angus. J’ai hâte de voir les résultats dans les semaines à venir !

Je suis intrigué par le nombre de parallèles avec mon domaine, l’informatique de la santé. Nous souffrons des mêmes problèmes de modèles de données propriétaires développés organiquement qui ne fonctionnent pas bien ensemble. Et les patients en souffrent en conséquence.

Il existe un projet impressionnant de données ouvertes qui cherche essentiellement à faire la même chose pour toutes les données de santé :

2 « J'aime »

Juste une autre mise à jour pour noter que notre travail de la phase 1 a été examiné favorablement par DAPSI et que ce projet progresse vers la phase 2, c’est-à-dire la construction du plugin d’intégration des événements. Une partie de cela impliquera une refonte du plugin d’intégration des événements Pavilion.

En effet. J’ai eu une bonne conversation avec @pacharanero à ce sujet lors du déjeuner à York.

5 « J'aime »

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 « J'aime »