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 travaille sur un plugin d’intégration d’événements pour Discourse (DEIP), qui, entre autres, vous permettra de publier des événements sur Discourse à partir d’autres services et plateformes. Nous avons soumis une proposition à DAPSI (un programme NGI de l’UE), qui a été acceptée pour financement. Le programme vient de démarrer (hier soir) et nous commençons les travaux. Cela chevauchera certains des points que vous avez soulevés.

Version révisée du résumé exécutif de la proposition

Il n’existe pas de modèle de données abstrait pour les événements calendaires couramment utilisé par les services en ligne de gestion d’événements. Nous allons d’abord spécifier et prototyper un modèle de données fonctionnel basé sur une assimilation des tentatives de normalisation précédentes et des modèles de données des services d’événements populaires (« Spécification et prototype DEIP »). Nous transformerons ensuite cette spécification en un produit commercialisable sous la forme d’un plugin Discourse open source permettant aux communautés en ligne de transférer facilement les données d’événements calendaires entre les plateformes de gestion d’événements populaires (initialement Eventbrite, Meetup et Zoom) et Discourse, le logiciel de communauté open source le plus populaire (« Produit DEIP »). Nous proposerons des abonnements orientés services aux entreprises utilisant le MVP pour assurer la viabilité continue du plugin dans le temps.

Le produit DEIP sera une alternative open source commercialement viable à l’API officielle des événements récemment lancée par Facebook, qui offre des fonctionnalités similaires, mais uniquement pour le « jardin clos » de données communautaires de Facebook. Facebook investit depuis quelque temps dans ses fonctionnalités communautaires, et cet investissement est en croissance. Le maintien de l’attention de Facebook sur cet aspect de son produit signifie que les alternatives open source doivent continuellement améliorer leurs offres équivalentes pour rester viables. La spécification et le produit DEIP seront des outils vitaux dans cette lutte.

Discourse est l’une des rares plateformes open source véritablement viables pour les communautés en ligne. C’est le projet communautaire le plus populaire sur GitHub, et il a récemment levé 20 millions de dollars US pour continuer à faire croître son organisation en expansion (55 employés soutenant plus de 32 000 communautés). La plateforme de Discourse est 100 % open source et est profondément ancrée dans les communautés et la culture du logiciel open source.

Pavilion (le demandeur) est une coopérative de développeurs et de chefs de produits et un partenaire officiel de Discourse. Nous travaillons avec Discourse depuis plus de 6 ans et avons construit une partie substantielle des plugins tiers existants pour Discourse, y compris le plugin Discourse le plus populaire et plusieurs plugins qui ont ensuite été adoptés (devenus « officiels ») par Discourse.org.

La combinaison de la spécification et du produit servira à la fois d’exponent de la normalisation des modèles de données d’événements calendaires et fournira une solution open source efficace pour la gestion d’événements sur les dizaines de milliers de communautés en ligne utilisant Discourse.

Résumé (Problème et solution)

Le problème principal rencontré par les communautés en ligne gérant des événements est l’intégration des services. Les communautés utilisent un mélange de plateformes de marketing comme Eventbrite, de plateformes de découverte comme meetup.com, d’outils de réunion comme Zoom, ou de solutions tout-en-un comme Facebook. La difficulté de gérer une communauté à travers plusieurs services incite à utiliser des solutions propriétaires qui offrent commodité au détriment de la transparence et de la portabilité.

Le DEIP sera à la fois une spécification de modèle de données d’événements calendaires et un prototype, ainsi qu’un plugin Discourse open source commercialement viable. En résumé, le DEIP permettra de :

  1. Définir une spécification pratique de modèle de données d’événements calendaires.
  2. Implémenter la spécification dans un prototype fonctionnel.
  3. Développer le prototype en un plugin Discourse avec support pour l’importation depuis des services d’événements populaires et l’exportation selon des standards de calendrier courants.
  4. Publier le plugin en tant que produit open source, avec un service d’abonnement ciblant les utilisateurs professionnels.

Spécification (Composante de recherche)

Les principaux standards dans la gestion des événements calendaires sont RFC 5545 (format .ics) et RFC 4791 (CalDAV, ou « flux iCal »). Le problème avec ces standards est qu’ils ne sont pas actuellement utilisés pour modéliser les données d’événements calendaires disponibles via les API modernes. Les objets équivalents disponibles via les API Eventbrite, Meetup et Zoom ne se traduisent ni vers RFC 5545, ni entre eux. Les tentatives d’organismes sectoriels pour développer une API de calendrier abstraite n’ont pas encore porté leurs fruits, malgré certaines tentatives récentes. De plus, les services propriétaires ne fournissent pas de flux CalDAV au niveau du groupe/site/communauté (ils fournissent parfois des flux spécifiques à l’utilisateur). En bref, il existe une carence significative dans la normalisation des modèles de données d’événements calendaires.

La composante principale de recherche du DEIP sera de spécifier un modèle de données d’événement abstrait qui implémente les tentatives de normalisation existantes, tout en maintenant une utilisabilité pratique vis-à-vis des services propriétaires liés aux événements les plus populaires (la « Spécification DEIP »). Cette spécification sera ensuite convertie en un prototype fonctionnel (initialement en Ruby, puis dans d’autres langages), permettant la création, la lecture, la mise à jour et la suppression d’événements calendaires génériques (le « Prototype DEIP »). Selon les résultats de ce travail, nous pourrons chercher à emballer le Prototype DEIP pour distribution via différents systèmes de paquets, par exemple des gems Ruby.

Outre la formation de la base du MVP (voir ci-dessous), la spécification et le prototype seront publiés sur la page d’accueil du DEIP avec des explications accompagnant la réflexion derrière ceux-ci. Nous consacrerons également une section de notre propre communauté à ce sujet pour une discussion approfondie. Nous souhaitons être une partie active des efforts visant à rapprocher les services logiciels d’événements de l’utilisation de modèles de données standardisés afin d’améliorer l’interopérabilité et la portabilité des services.

Développement (Composante de développement)

Nous développerons la Spécification et le Prototype DEIP en un MVP plugin Discourse offrant les fonctionnalités suivantes :

  • API d’événements Discourse avec support Création, Lecture et Suppression. Le support de mise à jour (c’est-à-dire la communication bidirectionnelle) sera ajouté dans une version ultérieure du produit.
  • Support spécifique pour les services populaires. Initialement Eventbrite, Meetup et Zoom.
  • Intégration avec le plugin Événements de Discourse pour afficher les événements dans les sujets Discourse et fournir un calendrier des événements au sein de Discourse lui-même.
  • Un serveur CalDAV pour fournir un flux unifié de tous les événements d’une communauté, avec la possibilité de filtrer par catégorie et par utilisateur.
  • Intégration avec le plugin Outils juridiques pour le support RGPD et le plugin Emplacements pour la cartographie des emplacements GeoJSON utilisant des solutions de cartographie open source.

Déploiement (Pertinence, impact et avantages)

Pavilion soutient des milliers de communautés en ligne grâce à nos travaux de conseil payants et à nos travaux open source non rémunérés, dont beaucoup ont clairement exprimé le besoin du produit DEIP, notamment des chercheurs universitaires, des communautés de soutien en santé, des amateurs, des petites entreprises, des quartiers, des startups, des organisations à but non lucratif, des entreprises du Fortune 500, des romanciers de fantasy et des passionnés de photographie de nature. Pour un aperçu de ce besoin, consultez ici, ici, ici, ici, ici, ici et ici. Le manque de facilité de portabilité et d’intégration des événements est souvent un facteur clé dans le choix entre des solutions propriétaires verrouillées comme Facebook et des solutions open source comme Discourse.

Les membres de Pavilion déploieront personnellement le produit DEIP pour nos clients existants qui organisent des événements, ainsi que pour aider les nombreux utilisateurs open source de nos travaux, comme ceux liés ci-dessus. En plus du travail de Pavilion au sein de la communauté Discourse, le DEIP aura :

Notre objectif est que le produit DEIP soit une alternative viable à la gestion d’événements sur les plateformes communautaires propriétaires et que la spécification et le prototype DEIP fassent progresser les efforts de normalisation des modèles de données d’événements calendaires.

Modèle économique (Exploitation commerciale)

Pavilion a développé un modèle d’abonnement pour nos plugins Discourse open source qui maintient nos engagements envers l’open source et le soutien aux communautés à but non lucratif, tout en assurant une rémunération appropriée de nos membres pour leur travail. Le modèle présente les caractéristiques suivantes :

  • Code 100 % open source.
  • Fonctionnalités « business » sélectionnées qui ne sont pas visibles sur le client de l’application sauf si le gestionnaire de communauté a acheté un abonnement.
  • Abonnements gratuits pour les communautés à but non lucratif qui utilisent les fonctionnalités « business ».
  • Services orientés vers les entreprises pour les abonnés payants.

La restriction des fonctionnalités dans une base de code 100 % open source peut être contournée programmatically, mais cela n’est pas pertinent pour le marché cible des abonnements payants. Les entreprises veulent payer pour des services qui leur sont bénéfiques, et ceux qui choisissent de contourner les restrictions ne sont pas les clients cibles pour cet aspect du produit.

Nous pourrions potentiellement étendre la portée de ce projet pour inclure certaines des autres choses que vous avez mentionnées, c’est-à-dire celles axées sur les fonctionnalités d’événements au sein de Discourse lui-même ; cependant, nous aurions besoin de financement supplémentaire. Si vous souhaitez en discuter davantage, vous pouvez m’envoyer un message privé à ce sujet. Dans tous les cas, je partagerai plus de détails sur le projet DEIP ici sur meta à mesure que nous avancerons.

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 »