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 sta lavorando a un plugin di integrazione per gli eventi di Discourse (DEIP), che, tra l’altro, consentirà di pubblicare eventi su Discourse da altri servizi e piattaforme. Abbiamo presentato una proposta a DAPSI (un programma NGI dell’UE), che è stata accettata per il finanziamento. Il programma è appena iniziato (ieri sera) e abbiamo iniziato a lavorare su di esso. Questo sovrapporrà alcuni dei punti da voi sollevati.

Versione modificata del riassunto esecutivo della proposta

Non esiste un modello di dati astratto per gli eventi del calendario utilizzato abitualmente dai servizi di eventi online. Specificheremo e prototipizzeremo prima un modello di dati funzionante basato sull’assimilazione di precedenti tentativi di standardizzazione e sui modelli di dati dei servizi di eventi più popolari (“Specifiche e Prototipo DEIP”). Successivamente, trasformeremo questa specifica in un prodotto sotto forma di plugin open source per Discourse che consentirà alle comunità online di trasferire facilmente i dati degli eventi del calendario tra le piattaforme di gestione eventi più diffuse (inizialmente Eventbrite, Meetup e Zoom) e Discourse, il software open source per comunità più popolare (“Prodotto DEIP”). Offriremo abbonamenti orientati al servizio alle aziende che utilizzano l’MVP per garantire la sostenibilità del plugin nel tempo.

Il Prodotto DEIP sarà un’alternativa open source commercialmente valida alla recente API Ufficiale Eventi di Facebook, che offre funzionalità simili, ma solo per il “giardino recintato” dei dati comunitari di Facebook. Facebook ha investito nelle sue funzionalità comunitarie da tempo e questo investimento sta crescendo. Il continuo focus di Facebook su questo aspetto del suo prodotto significa che le alternative open source devono migliorare continuamente le offerte equivalenti per rimanere vitali. Le Specifiche e il Prodotto DEIP saranno strumenti fondamentali in questa lotta.

Discourse è una delle poche piattaforme open source realmente vitali per le comunità online. È il progetto comunitario più popolare su GitHub e ha recentemente raccolto 20 milioni di dollari USA per far crescere ulteriormente la sua organizzazione in espansione (55 dipendenti a supporto di oltre 32.000 comunità). La piattaforma di Discourse è al 100% open source ed è profondamente radicata nelle comunità e nella cultura del software open source.

Pavilion (il richiedente) è una cooperativa di sviluppatori e product manager ed è un partner ufficiale di Discourse. Lavoriamo con Discourse da oltre 6 anni e abbiamo realizzato una parte sostanziale dei plugin di terze parti esistenti per Discourse, incluso il plugin Discourse più popolare e numerosi plugin che sono stati successivamente adottati (reso “ufficiale”) da Discourse.org.

La combinazione di Specifiche e Prodotto servirà sia come esponente della standardizzazione del modello di dati degli eventi del calendario, sia come soluzione open source efficiente per la gestione degli eventi nelle decine di migliaia di comunità online che utilizzano Discourse.

Riassunto (Problema e Soluzione)

Il problema principale affrontato dalle comunità online nella gestione degli eventi è l’integrazione dei servizi. Le comunità utilizzano un mix di piattaforme di marketing come Eventbrite, piattaforme di scoperta come meetup.com, strumenti di riunione come Zoom o soluzioni all-in-one come Facebook. La difficoltà di gestire una comunità su più servizi crea un incentivo a utilizzare soluzioni proprietarie che offrono comodità a scapito di trasparenza e portabilità.

Il DEIP sarà sia una specifica e un prototipo di modello di dati degli eventi del calendario, sia un plugin open source commercialmente valido per Discourse. In sintesi, il DEIP:

  1. Definisce una specifica pratica per il modello di dati degli eventi del calendario.
  2. Implementa la specifica in un prototipo funzionante.
  3. Sviluppa il prototipo in un plugin Discourse con supporto per l’importazione dai servizi di eventi più diffusi e l’esportazione utilizzando standard di calendari comuni.
  4. Rilascia il plugin come prodotto open source, con un servizio di abbonamento rivolto agli utenti aziendali.

Specifiche (La componente di ricerca)

I principali standard nella gestione degli eventi del calendario sono RFC 5545 (formato .ics) e RFC 4791 (CalDAV, o “feed iCal”). Il problema con questi standard è che attualmente non vengono utilizzati per modellare i dati degli eventi del calendario disponibili dalle API moderne. Gli oggetti equivalenti disponibili tramite le API Eventbrite, Meetup e Zoom non si traducono in RFC 5545, né tra loro. I tentativi degli organismi di settore di sviluppare un’API di calendariatura astratta non hanno ancora dato frutti, nonostante alcuni recenti tentativi. Inoltre, i servizi proprietari non forniscono feed CalDAV a livello di gruppo/sito/comunità (a volte forniscono feed specifici per utente). In breve, c’è una significativa carenza di standardizzazione del modello di dati degli eventi del calendario.

La componente principale della ricerca del DEIP sarà specificare un modello di dati degli eventi astratto che implementi i tentativi di standardizzazione esistenti, mantenendo al contempo un’utilità pratica rispetto ai servizi proprietari più popolari legati agli eventi (la “Specificazione DEIP”). Questa specifica verrà quindi convertita in un prototipo funzionante (inizialmente in Ruby; successivamente in altri linguaggi), consentendo la creazione, la lettura, l’aggiornamento e l’eliminazione di eventi del calendario generici (il “Prototipo DEIP”). A seconda dei risultati di questo lavoro, potremmo cercare di impacchettare il Prototipo DEIP per la distribuzione tramite diversi sistemi di pacchetti, ad esempio gemme Ruby.

Oltre a formare la base dell’MVP (vedi sotto), la specifica e il prototipo verranno pubblicati sulla pagina di atterraggio del DEIP con spiegazioni accompagnatorie del pensiero alla base. Dedicheremo anche una sezione della nostra comunità per ulteriori discussioni. Vogliamo essere parte attiva degli sforzi per avvicinare i servizi software degli eventi all’uso di modelli di dati standard per migliorare l’interoperabilità e la portabilità dei servizi.

Sviluppo (La componente di sviluppo)

Svilupperemo la Specifica e il Prototipo DEIP in un MVP Plugin Discourse che offre le seguenti funzionalità:

  • API Eventi Discourse con supporto per Creazione, Lettura ed Eliminazione. Il supporto per l’aggiornamento (cioè la comunicazione bidirezionale) verrà aggiunto in una versione successiva del prodotto.
  • Supporto specifico per i servizi più diffusi. Inizialmente Eventbrite, Meetup e Zoom.
  • Integrazione con il Plugin Eventi Discourse per visualizzare gli eventi all’interno dei topic di Discourse e fornire un Calendario Eventi all’interno dello stesso Discourse.
  • Un server CalDAV per fornire un feed unificato di tutti gli eventi in una comunità, con la possibilità di filtrare per categoria e utente.
  • Integrazione con il Plugin Strumenti Legali per il supporto GDPR e il Plugin Luoghi per la mappatura delle località GeoJSON utilizzando soluzioni di mappatura open source.

Distribuzione (Rilevanza, impatto e benefici)

Pavilion supporta migliaia di comunità online attraverso il nostro lavoro di consulenza a pagamento e il lavoro open source non retribuito, molte delle quali hanno espresso un chiaro bisogno del Prodotto DEIP, tra cui ricercatori universitari, comunità di supporto alla salute, hobbisti, piccole imprese, quartieri, startup, organizzazioni non profit, aziende Fortune-500, scrittori di romanzi fantasy e appassionati di fotografia naturalistica. Per un campione di questo bisogno, vedi qui, qui, qui, qui, qui, qui e qui. La mancanza di facilità di portabilità e integrazione degli eventi è spesso un fattore chiave nella scelta tra soluzioni proprietarie chiuse come Facebook e soluzioni open source come Discourse.

I membri di Pavilion distribuiranno personalmente il Prodotto DEIP per i nostri clienti esistenti che organizzano eventi, oltre ad assistere i numerosi utenti open source del nostro lavoro, come quelli collegati sopra. Oltre al lavoro di Pavilion all’interno della comunità Discourse, il DEIP avrà:

Il nostro obiettivo è che il Prodotto DEIP sia un’alternativa valida alla gestione degli eventi sulle piattaforme comunitarie proprietarie e che la Specifica e il Prototipo DEIP avanzino gli sforzi di standardizzazione del modello di dati degli eventi del calendario.

Modello di business (Sfruttamento commerciale)

Pavilion ha sviluppato un modello di abbonamento per i nostri plugin open source di Discourse che mantiene i nostri impegni verso l’open source e il supporto delle comunità non profit, garantendo al contempo che i nostri membri siano adeguatamente compensati per il loro lavoro. Il modello ha le seguenti caratteristiche:

  • Codice al 100% open source.
  • Funzionalità “aziendali” selezionate non visibili sul client dell’applicazione a meno che il responsabile della comunità non abbia acquistato un abbonamento.
  • Abbonamenti gratuiti per le comunità non profit che utilizzano le funzionalità “aziendali”.
  • Servizi orientati alle aziende per gli abbonati a pagamento.

La restrizione delle funzionalità in una base di codice al 100% open source può essere superata programmaticamente, tuttavia questo non è rilevante per il mercato di riferimento per gli abbonamenti a pagamento. Le aziende vogliono pagare per servizi che li avvantaggiano, e coloro che scelgono di superare le restrizioni non sono i clienti target per quell’aspetto del prodotto.

Potremmo potenzialmente ampliare l’ambito di questo progetto per includere alcune delle altre cose che avete menzionato, cioè quelle focalizzate sulle funzionalità degli eventi all’interno dello stesso Discourse; tuttavia, avremmo bisogno di finanziamenti aggiuntivi. Se volete discuterne ulteriormente, potete inviarmi un messaggio privato. In ogni caso, condividerò ulteriori dettagli sul progetto DEIP qui su meta mentre procediamo.

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