Funciones del plugin de calendario para que sea realmente útil para nosotros

Característica
1

Continuando la discusión de Discourse Calendar:

El Proyecto Fedora tiene actualmente nuestra propia aplicación web de calendario, Fedocal. Está programada para una actualización y estoy pensando si podríamos reemplazar los calendarios en Discourse en lugar de reescribir la aplicación independiente. Esto no es realmente una solicitud de características, sino una recopilación de nuestros casos de uso y de lo que considero que falta mientras evaluamos qué hacer.

Casos de uso

Veo tres casos de uso importantes para Fedocal. Si hay más, por favor házmelo saber y los añadiré a la consideración.

  1. Programación de reuniones. Este es, con diferencia, el más importante.
  2. Permitir que las personas compartan su disponibilidad. Actualmente pedimos a las personas con responsabilidad en el proyecto que ingresen esto para las vacaciones, pero pocas personas lo hacen realmente. (Yo, personalmente, lo encuentro demasiado engorroso cuando lo recuerdo).
  3. Mostrar eventos de Fedora como Flock to Fedora, Semana de la Diversidad o Fiestas de Lanzamiento. En realidad, no hacemos esto hoy.

Otras posibilidades

  • Intentamos usar Fedocal para el horario de la conferencia Flock en 2013, pero no lo hemos hecho desde entonces. Sería agradable tener una solución que lo hiciera atractivo y fácil.
  • Mostrar el propio calendario de lanzamientos de Fedora. Actualmente, creo que solo lo usamos para programar las reuniones de aprobación/rechazo, no el horario en sí. Si hiciéramos esto, debería provenir automáticamente de Fedora Project schedules en lugar de requerir una entrada manual.

Deficiencias del plugin de calendario de Discourse actual

El sistema de “eventos” que se está agregando actualmente es incorrecto para lo que necesitamos. (Recopila “eventos” de publicaciones de todo el sitio y los pone en un único calendario global. Necesitamos mucho más que eso).

Mi primera suposición es que nos centraríamos en extender la parte “tradicional” del plugin de calendario, que tiene un calendario en la primera respuesta a un tema que se “alimenta” de las respuestas a ese tema solamente. Sin embargo, podría ser posible que el otro enfoque —recopilar eventos de todo el sitio— fuera mejor. En ese caso, sin embargo, necesitaríamos extenderlo para poder tener múltiples calendarios de destino. (Y en ese caso, sería bueno poder incrustarlos en temas fijados, no solo ocultarlos en el menú de hamburguesa).

Dicho esto, aquí hay algunas cosas que necesitaríamos:

En general

  1. La visualización del calendario en sí es bastante rudimentaria.
    • Podría ser mucho más bonito
    • No escala ni se adapta de ninguna manera a cómo se muestra
    • Está codificado de forma rígida para semanas de lunes a domingo al estilo de la UE
    • Parece mostrar siempre los días en UTC, a pesar de que las entradas están en zonas horarias locales, lo que hace que los eventos de todo el día en una zona horaria local parezcan abarcar dos días en el calendario. (El equipo de Discourse está al tanto de este error).
    • La vista mensual actualmente solo muestra los primeros caracteres de la descripción de un evento. Eso está bien si el calendario es solo para una cosa simple (ver en uso aquí para Fedora Social Hour, pero no es bueno para un calendario con muchas cosas diferentes.
    • Actualmente, la versión “Festivos” del calendario puede asignar colores a los eventos, pero lo hace utilizando un valor derivado programáticamente del nombre de usuario. Esto debería ser configurable por evento y aplicarse a todos los calendarios, no solo al de festivos.
  2. No creo que haya un feed .ical. Sería bueno que las personas pudieran agregarlo a su Google Calendar o lo que sea.
  3. Agradable tener: capacidad de generar correos electrónicos de recordatorio enviados a listas de correo, no solo a usuarios suscritos. ¡Todavía no tenemos a todos en Discourse!
  4. Agradable tener: una vista de calendario personal donde se opta por rastrear exactamente qué entradas.

Caso de uso de reuniones

  1. Fedocal tiene dos “ejes” principales: el grupo al que pertenece la entrada del calendario (como “consejo”) y la ubicación (como “#fedora-meeting”). El plugin de calendario puede hacer una cosa u otra: podemos crear un tema “Reuniones del Consejo de Fedora” o un tema “Canal de Reuniones de Fedora”, pero las entradas no estarían vinculadas. No estoy muy seguro de cuál sería el mejor diseño para eso como plugin; creo que podríamos usar algo de experiencia en diseño UX para pensar en ello.
    • estaría bien si el eje “grupo” fueran grupos de Discourse, especialmente porque algún día pronto espero vamos a vincular los grupos de Discourse a nuestro SSO.
    • o, posiblemente, el eje “grupo” del calendario podría ser una etiqueta. Eso podría ser más flexible y nos funcionaría porque planeamos un mapeo de grupo a etiqueta para la organización de nuestro sitio.
    • el eje “ubicaciones” es corto: tenemos un puñado de canales de reunión, y probablemente sea suficiente permitir una ubicación “otra” para casos extraños.
  2. Crítico: El sistema necesita prevenir —o al menos advertir sobre— conflictos en ambos ejes. Es decir, no puede haber dos reuniones del grupo del consejo al mismo tiempo, y no puede haber dos reuniones de un grupo diferente en la misma ubicación al mismo tiempo.
    • excepto si tenemos un “otro” comodín… así que, supongo que algunas ubicaciones deberían poder tener superposiciones.
  3. La sintaxis para eventos repetidos es un poco extraña, pero está bien. Sin embargo, los eventos repetidos solo aparecen en la cuadrícula del calendario como repetidos (y en el recordatorio se actualizan al siguiente), nada más. Y debería haber más:
    • Crítico: Debería ser posible que los usuarios se suscriban a una notificación para cada evento repetido, por entrada de calendario individual.
      • Agradable tener: una configuración por grupo de Discourse para las notificaciones predeterminadas para un calendario particular, de modo que, por ejemplo, los miembros del grupo del consejo reciban notificaciones por defecto para las entradas del calendario del consejo.
      • Agradable tener: capacidad de configurar también notificaciones de advertencia de 15 minutos para las próximas reuniones.
    • Importante: Debería ser posible marcar eventos específicos para omitirlos (o para que se realicen en un momento diferente) sin cambiar todo.
  4. Ahora mismo, la duración del evento se hace con entradas como [date=2021-11-28 time=12:00:00 timezone="America/New_York"] → [date=2021-11-28 time=13:00:00 timezone="America/New_York"]. Eso es tedioso de ingresar y el resultado (2021-11-28T17:00:00Z → 2021-11-28T18:00:00Z) no es inmediatamente obvio. Sería bueno tener [date=2021-11-28 time=12:00:00 timezone="America/New_York" duration="1 hour"] en su lugar.
    1. Agradable tener: Las entradas sin duración deberían ser visualmente diferentes — y quizás solo permitidas para entradas de “todo el día”.
  5. Agradable tener: cada entrada de calendario (por separado para las repetidas) podría tener un enlace a un tema de agenda + notas. Este tema no se crearía automáticamente sin interacción, pero debería ser fácil de iniciar con un clic y, una vez creado, enlazado automáticamente.

Caso de uso de “Festivos”

  1. El calendario de festivos también debería ser consciente de los grupos. Actualmente tiene algunas especializaciones para el personal (del sitio de Discourse): eso debería generalizarse y configurarse, y se permitirían diferentes calendarios para diferentes grupos, así como uno global.
  2. En su configuración predeterminada, el calendario de festivos muestra los días festivos nacionales estándar para cada persona que tiene configurada su configuración regional. Si eso es más que, digamos, cinco personas en no más de dos ubicaciones diferentes, abruma todo lo demás. Sin embargo, Discourse nos ha proporcionado una solución temporal para ocultar eso.
  3. Agradable tener: Actualmente, los miembros del personal reciben un emoji :palm_tree: junto a su nombre de usuario cuando están de vacaciones, solo visible para otros miembros del personal. La visibilidad de este icono debería ser configurable.
  4. Agradable tener: permitir la configuración del emoji que se muestra.
    • Bonificación agradable de tener: permitir a los usuarios seleccionar de una lista de emojis y razones para un período de indisponibilidad determinado (vacaciones, enfermedad, viaje, etc.)

Eventos de Fedora

De hecho, creo que lo que tenemos hoy podría funcionar para esto. Sin embargo, algunas de las cosas anteriores —una visualización del calendario más bonita y flexible, notificaciones, colores— serían útiles.

Para otras posibilidades

  • El caso de uso del horario de conferencias es simplemente el caso de uso de la programación de reuniones, pero de forma muy intensa. Mantener un registro manual de los conflictos se vuelve imposible. Para esto, puede que necesitemos un eje a nivel de usuario en lugar de un eje a nivel de grupo. (Los ponentes no pueden estar en dos lugares a la vez). Y a diferencia de nuestras salas de reuniones, que no han cambiado mucho en 15 años (excepto por las actualizaciones de URL) y probablemente no lo harán en otros 15, cada evento tiene su propio conjunto de ubicaciones.
  • Calendario de lanzamientos: Creo que esto es principalmente una cuestión de automatización en la importación de los datos del horario existente. El plugin de calendario existente podría funcionar en su mayor parte, creo. De nuevo, como con los eventos de Fedora, la codificación por colores sería agradable.
14 Me gusta
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 Me gusta
3

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡

8 Me gusta
4

Hola Angus,

¿Has progresado en esto? Es un problema constante para todos mis foros y que lleva a la gente a otras plataformas para reunirse y cosas por el estilo.

2 Me gusta
5

Hola Nathan, tendremos algunas cosas que compartir en aproximadamente un mes. Mientras tanto, puedes contactarme en privado en coop.pavilion.tech y puedo ayudarte a configurar eventos en tu foro.

Además del proyecto DEIP, estamos pensando en revivir el Plugin de Eventos y podemos usarlo para abordar algunas de las preocupaciones mencionadas anteriormente.

4 Me gusta
6

Como prometí, aquí está el informe completo sobre la Fase 1 del proyecto del plugin de integración de eventos de Discourse.

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

Y aquí está la implementación prototipo del modelo de datos de eventos (una gema de Ruby). Tenga en cuenta que la gema está en desarrollo y no está lista para uso en producción.

https://github.com/paviliondev/omnievent

Como se desprende de la lectura del informe de investigación, el plugin en sí se construirá en la Fase 2 del proyecto.

4 Me gusta
7

Es un trabajo impresionante, Angus. ¡Espero ver los frutos en el próximo tiempo!

Me intriga cuántos paralelismos hay con mi campo de la informática de la salud. Sufrimos los mismos problemas de múltiples modelos de datos propietarios desarrollados orgánicamente que no funcionan bien. Y los pacientes sufren como resultado.

Hay un impresionante proyecto de datos abiertos que esencialmente busca hacer lo mismo para todos los datos de salud:

2 Me gusta
8

Solo otra actualización para señalar que nuestro trabajo en la Fase 1 fue revisado favorablemente por DAPSI y este proyecto está progresando a la Fase 2, es decir, la construcción del Plugin de Integración de Eventos. Parte de esto implicará una renovación del Plugin de Eventos Pavilion.

De hecho. Tuve una buena charla con @pacharanero sobre esta superposición durante el almuerzo en York.

5 Me gusta
9

Solo una nota final aquí que la versión beta del Plugin de Integración de Eventos ya está disponible :slight_smile:

Publicaré más actualizaciones en ese tema.

5 Me gusta