Funzionalità del plugin Calendario per renderlo davvero utile per noi

Continuando la discussione da Discourse Calendar:

Il Fedora Project ha attualmente la nostra web app di calendario, Fedocal. È in programma un aggiornamento e sto valutando se potremmo sostituire i calendari su Discourse invece di riscrivere l’app stand-alone. Questa non è una richiesta di funzionalità, ma piuttosto una raccolta dei nostri casi d’uso e di ciò che ritengo manchi mentre valutiamo cosa fare.

Casi d’uso

Ci sono tre casi d’uso importanti che vedo per Fedocal. Se ce ne sono altri, per favore fatemelo sapere e li aggiungerò alla considerazione.

  1. Pianificazione delle riunioni. Questo è di gran lunga il più importante.
  2. Consentire alle persone di condividere la propria disponibilità. Attualmente chiediamo alle persone con responsabilità nel progetto di inserirla per le ferie, ma poche persone lo fanno effettivamente. (Io, personalmente, la trovo troppo complicata anche quando mi ricordo.)
  3. Mostrare eventi Fedora come Flock to Fedora, Week of Diversity o Release Parties. In realtà non lo facciamo oggi.

Altre possibilità

  • Abbiamo provato a usare Fedocal per il programma della conferenza Flock nel 2013, ma non lo facciamo da allora. Sarebbe bello avere una soluzione che lo renda attraente e facile.
  • Mostrare il programma di rilascio di Fedora stesso. Attualmente, penso che lo usiamo solo per pianificare le riunioni go/no-go, non il programma effettivo. Se lo facessimo, dovrebbe provenire automaticamente da Fedora Project schedules invece di richiedere un inserimento manuale.

Carenze dell’attuale plugin Calendario di Discourse

Il sistema “eventi” che viene aggiunto ad esso è attualmente sbagliato per ciò di cui abbiamo bisogno. (Raccoglie “eventi” dai post di tutto il sito e li inserisce in un unico calendario globale. Abbiamo bisogno di molto di più.)

La mia prima ipotesi è che ci concentreremo sull’estensione della parte “tradizionale” del plugin del calendario, che ha un calendario nella prima risposta a un argomento che viene “alimentato” dalle risposte a quell’argomento da solo. Tuttavia, potrebbe essere possibile che l’altro approccio — raccogliere eventi da tutto il sito — sarebbe migliore. In tal caso, però, dovremmo estenderlo per poter avere più calendari da indirizzare. (E in tal caso sarebbe bello poterli incorporare in argomenti fissati, non solo nasconderli nel menu hamburger.)

Quindi, detto questo, ecco alcune cose di cui avremmo bisogno:

In generale

  1. La visualizzazione del calendario stessa è piuttosto rudimentale.
    • Potrebbe essere molto più bella
    • Non scala né si adatta in alcun modo a come viene visualizzato
    • È codificata in modo fisso per settimane da lunedì a domenica in stile UE
    • Sembra mostrare sempre i giorni in UTC, anche se le voci sono nei fusi orari locali, il che fa sì che eventi di un giorno intero in un fuso orario locale possano apparire come se coprissero due giorni sul calendario. (Il team di Discourse è a conoscenza di questo bug.)
    • La vista mensile mostra attualmente solo i primi caratteri della descrizione di un evento. Va bene se il calendario riguarda solo una cosa semplice (vedi in uso qui per Fedora Social Hour, ma non va bene per un calendario con molte cose diverse.
    • Attualmente, la versione “Holiday” del calendario può assegnare colori agli eventi, ma lo fa utilizzando un valore derivato programmaticamente dal nome utente. Questo dovrebbe invece essere configurabile su base per evento e applicarsi a tutti i calendari, non solo a quello delle festività.
  2. Non credo ci sia un feed .ical? Sarebbe bello per le persone poterlo aggiungere al proprio Google Calendar o altro.
  3. Bello averlo: possibilità di generare email di promemoria inviate alle mailing list, non solo agli utenti iscritti. Non abbiamo ancora tutti su Discourse!
  4. Bello averlo: una vista calendario personale in cui si sceglie a quali voci specifiche prestare attenzione.

Caso d’uso Riunioni

  1. Fedocal ha due “assi” principali: il gruppo a cui appartiene la voce del calendario (come “consiglio”) e la posizione (come “#fedora-meeting”). Il plugin del calendario può fare una cosa o l’altra: possiamo creare un argomento “Riunioni del Consiglio Fedora” o un argomento “Canale Riunioni Fedora”, ma le voci non sarebbero collegate. Non sono molto sicuro di quale sarebbe il miglior design per questo come plugin: penso che potremmo usare un po’ di competenza di un UX designer per pensarci.
    • andrebbe benissimo se l’asse “gruppo” fossero i gruppi di Discourse, soprattutto perché un giorno presto spero collegheremo i gruppi di Discourse al nostro SSO.
    • oppure, possibilmente, l’asse “gruppo” del calendario potrebbe essere un tag. Ciò potrebbe essere più flessibile e funzionerebbe per noi perché stiamo pianificando una mappatura gruppo-tag per l’organizzazione del nostro sito.
    • l’asse “posizioni” è breve: abbiamo una manciata di canali di riunione, ed è probabilmente sufficiente consentire una posizione “altro” per casi particolari.
  2. Critico: Il sistema deve prevenire — o almeno avvisare su — conflitti su entrambi gli assi. Cioè, non ci possono essere due riunioni del gruppo del consiglio contemporaneamente, e non ci possono essere due riunioni di un gruppo diverso nella stessa posizione contemporaneamente.
    • tranne se abbiamo un “altro” generico… quindi, immagino che alcune posizioni dovrebbero consentire sovrapposizioni.
  3. La sintassi per gli eventi ricorrenti è un po’ strana, ma va bene. Tuttavia, gli eventi ricorrenti appaiono sul griglia del calendario come ricorrenti (e nel promemoria aggiornati al successivo), niente di più. E dovrebbero esserci più cose:
    • Critico: Dovrebbe essere possibile per gli utenti iscriversi a una notifica per ogni evento ricorrente, su base per voce di calendario.
      • Bello averlo: una configurazione per gruppo Discourse per le notifiche predefinite per un particolare calendario, in modo che, ad esempio, i membri del gruppo del consiglio ricevano per impostazione predefinita notifiche per le voci del calendario del consiglio.
      • Bello averlo: possibilità di configurare anche notifiche di avviso di 15 minuti per le riunioni imminenti.
    • Importante: Dovrebbe essere possibile contrassegnare eventi specifici come da saltare (o da tenere in un momento diverso) senza modificare l’intera cosa.
  4. Al momento, la durata dell’evento è fatta con voci come [date=2021-11-28 time=12:00:00 timezone="America/New_York"] → [date=2021-11-28 time=13:00:00 timezone="America/New_York"]. È noioso da inserire e il risultato (2021-11-28T17:00:00Z2021-11-28T18:00:00Z) non è immediatamente ovvio. Sarebbe bello avere invece [date=2021-11-28 time=12:00:00 timezone="America/New_York" duration="1 hour"].
    1. Bello averlo: Le voci senza durata dovrebbero essere visivamente diverse — e forse consentite solo per le voci “tutto il giorno”.
  5. Bello averlo: ogni voce del calendario (separatamente per quelle ricorrenti) potrebbe avere un link a un argomento per l’ordine del giorno + note. Questo argomento non verrebbe creato automaticamente senza interazione, ma dovrebbe essere facile da avviare con un clic e, una volta creato, collegato automaticamente.

Caso d’uso “Festività”

  1. Il calendario delle festività dovrebbe anche essere consapevole dei gruppi. Attualmente ha alcune speciali condizioni per lo Staff (del sito Discourse) — questo dovrebbe essere generalizzato e configurabile, e dovrebbero essere consentiti calendari diversi per gruppi diversi, oltre a uno globale.
  2. Nella sua configurazione predefinita, il calendario delle festività mostra le festività nazionali standard per ogni persona che ha configurato la propria localizzazione. Se ci sono più di, diciamo, cinque persone in non più di due località diverse, sovrasta tutto il resto. Discourse ci ha fornito un hack temporaneo per nasconderlo, però.
  3. Bello averlo: Attualmente i membri dello staff ricevono un’emoji :palm_tree: accanto al loro nome utente quando sono in vacanza, visibile solo agli altri membri dello staff. La visibilità di questa icona dovrebbe essere configurabile.
  4. Bello averlo: consentire la configurazione dell’emoji mostrata.
    • Bonus bello averlo: consentire agli utenti di scegliere da un elenco di emoji e motivi per un dato periodo di indisponibilità (vacanza, malattia, viaggio, ecc.)

Eventi Fedora

In realtà, penso che ciò che abbiamo oggi potrebbe funzionare per questo. Tuttavia, alcune delle cose di cui sopra — visualizzazione del calendario più bella e flessibile, notifiche, colori — sarebbero utili.

Per altre possibilità

  • Il caso d’uso del programma della conferenza è solo il caso d’uso del programma delle riunioni, ma in modo molto intenso. Tenere traccia manualmente dei conflitti diventa impossibile. Per questo, potrebbe essere necessario un asse a livello utente invece di un asse a livello di gruppo. (Gli oratori non possono essere in due posti contemporaneamente). E a differenza delle nostre sale riunioni, che non sono cambiate molto negli ultimi 15 anni (tranne per gli aggiornamenti degli URL) e probabilmente non cambieranno nei prossimi 15, ogni evento ha il suo set di posizioni.
  • Calendario del programma di rilascio: penso che si tratti principalmente di automatizzare l’importazione dai dati del programma esistenti. Il plugin del calendario esistente potrebbe funzionare per la maggior parte, penso. Di nuovo, come con gli Eventi Fedora, la codifica a colori sarebbe bella.
14 Mi Piace

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 Mi Piace

Congratulazioni, Angus!!! È fantastico. Questo ha il potenziale per contribuire in modo significativo a un mondo migliore (non solo a un mucchio di Forum, ma anche questo è bello). Che tu possa riuscirci!

8 Mi Piace

Ciao Angus,

Hai fatto progressi in merito? È un problema sempre presente per tutti i miei forum, e che spinge le persone verso altre piattaforme per incontri e simili.

2 Mi Piace

Ciao Nathan, avremo delle novità da condividere tra circa un mese. Nel frattempo, puoi contattarmi privatamente su coop.pavilion.tech e posso aiutarti a organizzare eventi sul tuo forum.

Oltre al progetto DEIP, stiamo pensando di ripristinare il Plugin Eventi e potremmo usarlo per affrontare alcune delle preoccupazioni menzionate sopra.

4 Mi Piace

Come promesso, ecco il rapporto completo sulla Fase 1 del progetto Discourse Events Integration Plugin.

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

Ed ecco l’implementazione prototipo del modello di dati degli eventi (una gemma ruby). Nota che la gemma è in fase di sviluppo e non è pronta per l’uso in produzione.

https://github.com/paviliondev/omnievent

Come noterai leggendo il rapporto di ricerca, il plugin stesso sarà costruito nella Fase 2 del progetto.

4 Mi Piace

È un lavoro impressionante, Angus. Non vedo l’ora di vedere i risultati nel prossimo futuro!

Sono incuriosito da quanti paralleli ci siano con il mio campo dell’informatica sanitaria. Soffriamo gli stessi problemi di modelli di dati proprietari cresciuti organicamente che non interagiscono bene. E i pazienti ne soffrono come risultato.

C’è un impressionante progetto open data che essenzialmente cerca di fare lo stesso per tutti i dati sanitari:

2 Mi Piace

Solo un altro aggiornamento per segnalare che il nostro lavoro nella Fase 1 è stato esaminato favorevolmente da DAPSI e questo progetto sta progredendo alla Fase 2, ovvero la costruzione del plugin di integrazione degli eventi. Parte di questo comporterà una revisione del plugin Events Integration.

Infatti. Ho avuto una bella chiacchierata con @pacharanero su questa sovrapposizione durante il pranzo a York.

5 Mi Piace

Solo un’ultima nota qui che la versione beta del plugin di integrazione eventi è ora disponibile :slight_smile:

Pubblicherò ulteriori aggiornamenti in quell’argomento.

5 Mi Piace