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

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:00Z2021-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

Pavilion está trabajando en un Plugin de Integración de Eventos para Discourse (DEIP), que, entre otras cosas, permitirá publicar eventos en Discourse desde otros servicios y plataformas. Hemos presentado una propuesta a DAPSI (un programa NGI de la UE), la cual fue aceptada para su financiación. El programa acaba de comenzar (anoche) y estamos dando inicio al trabajo. Esto se superpondrá con algunos de los puntos que has planteado.

Versión editada del resumen ejecutivo de la propuesta

No existe un modelo de datos abstracto para eventos de calendario en uso habitual por parte de los servicios de eventos en línea. Primero especificaremos y prototiparemos un modelo de datos funcional basado en la asimilación de intentos anteriores de estandarización y en los modelos de datos de servicios de eventos populares («Especificación y Prototipo DEIP»). Posteriormente, comercializaremos esta especificación en forma de un plugin de código abierto para Discourse que permitirá a las comunidades en línea transferir fácilmente datos de eventos de calendario entre plataformas populares de gestión de eventos (inicialmente Eventbrite, Meetup y Zoom) y Discourse, el software de comunidad de código abierto más popular («Producto DEIP»). Ofreceremos suscripciones orientadas a servicios para empresas que utilicen el MVP (Producto Mínimo Viable) para garantizar la viabilidad continua del plugin a lo largo del tiempo.

El Producto DEIP será una alternativa de código abierto y comercialmente viable a la recientemente lanzada API Oficial de Eventos de Facebook, que ofrece funcionalidades similares, pero para el «jardín amurallado» de datos de comunidad de Facebook. Facebook ha estado invirtiendo en sus funciones comunitarias durante algún tiempo, y esa inversión está creciendo. El enfoque continuo de Facebook en este aspecto de su producto significa que las alternativas de código abierto deben mejorar continuamente ofertas equivalentes para mantenerse viables. La Especificación y el Producto DEIP serán herramientas vitales en esa lucha.

Discourse es una de las pocas plataformas de código abierto realmente viables para comunidades en línea. Es el proyecto comunitario más popular en GitHub y recientemente recaudó 20 millones de dólares estadounidenses para seguir impulsando el crecimiento de su organización en expansión (55 empleados que apoyan a más de 32.000 comunidades). La plataforma de Discourse es 100 % de código abierto y está profundamente integrada en las comunidades y la cultura del software de código abierto.

Pavilion (el solicitante) es una cooperativa de desarrolladores y gerentes de producto y un socio oficial de Discourse. Hemos estado trabajando con Discourse durante más de 6 años y hemos construido una parte sustancial de los plugins de terceros existentes para Discourse, incluyendo el plugin de Discourse más popular y una serie de plugins que posteriormente fueron adoptados (convertidos en «oficiales») por Discourse.org.

La combinación de la Especificación y el Producto servirá tanto como exponente de la estandarización del modelo de datos de eventos de calendario, como proporcionará una solución eficiente de código abierto para la gestión de eventos en las decenas de miles de comunidades en línea que utilizan Discourse.

Resumen (Problema y Solución)

El problema principal que enfrentan las comunidades en línea que gestionan eventos es la integración de servicios. Las comunidades utilizan una mezcla de plataformas de marketing como Eventbrite, plataformas de descubrimiento como meetup.com, herramientas de reuniones como Zoom, o soluciones todo en uno como Facebook. La dificultad de gestionar una comunidad a través de múltiples servicios significa que existe un incentivo para utilizar soluciones propietarias que ofrecen conveniencia sobre transparencia y portabilidad.

El DEIP será tanto una especificación y prototipo de modelo de datos de eventos de calendario, como un plugin de Discourse de código abierto y comercialmente viable. En resumen, el DEIP:

  1. Definirá una especificación práctica de modelo de datos de eventos de calendario.
  2. Implementará la especificación en un prototipo funcional.
  3. Desarrollará el prototipo en un plugin de Discourse con soporte para importar desde servicios de eventos populares y exportar utilizando estándares comunes de calendario.
  4. Lanzará el plugin como un producto de código abierto, con un servicio de suscripción dirigido a usuarios empresariales.

Especificación (El componente de investigación)

Los principales estándares en la gestión de eventos de calendario son RFC 5545 (formato .ics) y RFC 4791 (CalDAV, o «feeds iCal»). El problema con estos estándares es que actualmente no se utilizan para modelar los datos de eventos de calendario disponibles en las APIs modernas. Los objetos equivalentes disponibles a través de las APIs de Eventbrite, Meetup y Zoom no se traducen a RFC 5545, ni entre sí. Los intentos de organismos sectoriales para desarrollar una API de Calendariado Abstracto aún no han dado frutos, a pesar de algunos intentos recientes. Además, los servicios propietarios no proporcionan feeds CalDAV a nivel de grupo/sitio/comunidad (a veces proporcionan feeds específicos de usuario). En resumen, existe una escasez significativa de estandarización del modelo de datos de eventos de calendario.

El componente principal de investigación del DEIP será especificar un modelo de datos de eventos abstracto que implemente los intentos de estandarización existentes, manteniendo al mismo tiempo una usabilidad práctica en relación con los servicios propietarios relacionados con eventos más populares («Especificación DEIP»). Esta especificación se convertirá luego en un prototipo funcional (inicialmente en Ruby; posteriormente en otros lenguajes), permitiendo la creación, lectura, actualización y eliminación de eventos de calendario genéricos («Prototipo DEIP»). Dependiendo de los resultados de este trabajo, podríamos buscar empaquetar el Prototipo DEIP para su distribución a través de diferentes sistemas de paquetes, por ejemplo, gemas de Ruby.

Además de formar la base del MVP (ver más abajo), la especificación y el prototipo se publicarán en la página de aterrizaje del DEIP junto con explicaciones acompañantes sobre el razonamiento detrás de ellos. También dedicaremos una sección de nuestra propia comunidad a ello para mayor discusión. Queremos ser una parte activa de los esfuerzos para acercar los servicios de software de eventos al uso de modelos de datos estándar y mejorar la interoperabilidad y portabilidad de los servicios.

Desarrollo (El componente de desarrollo)

Desarrollaremos la Especificación y el Prototipo DEIP en un MVP Plugin de Discourse que ofrezca las siguientes características:

  • API de Eventos de Discourse con soporte para Crear, Leer y Eliminar. El soporte para Actualizar (es decir, comunicación bidireccional) se añadirá en una versión posterior del producto.
  • Soporte específico para servicios populares. Inicialmente Eventbrite, Meetup y Zoom.
  • Integración con el Plugin de Eventos de Discourse para mostrar eventos dentro de los temas de Discourse y proporcionar un Calendario de Eventos dentro del propio Discourse.
  • Un servidor CalDAV para proporcionar un feed unificado de todos los eventos en una comunidad, con la capacidad de filtrar por categoría y usuario.
  • Integración con el Plugin de Herramientas Legales para soporte de GDPR y el Plugin de Ubicaciones para mapeo de ubicaciones GeoJSON utilizando soluciones de mapeo de código abierto.

Despliegue (Relevancia, impacto y beneficios)

Pavilion apoya a miles de comunidades en línea a través de nuestro trabajo de consultoría pagado y nuestro trabajo de código abierto sin remuneración, muchas de las cuales han manifestado una clara necesidad del Producto DEIP, incluyendo investigadores universitarios, comunidades de apoyo en salud, aficionados, pequeñas empresas, vecindarios, startups, organizaciones sin fines de lucro, empresas Fortune 500, novelistas de fantasía y entusiastas de la fotografía de naturaleza. Para una muestra de esta necesidad, véase aquí, aquí, aquí, aquí, aquí, aquí y aquí. La falta de facilidad de portabilidad e integración de eventos es frecuentemente un factor clave en la elección entre soluciones propietarias de bloqueo como Facebook y soluciones de código abierto como Discourse.

Los miembros de Pavilion desplegarán personalmente el Producto DEIP para nuestros clientes existentes que organizan eventos, así como ayudando a los muchos usuarios de código abierto de nuestro trabajo, como los mencionados anteriormente. Además del trabajo de Pavilion dentro de la comunidad de Discourse, el DEIP tendrá:

  • Un sitio web de producto independiente, que incluye la Especificación y el Prototipo DEIP.
  • Documentación de la API.
  • Soporte a través de los canales de soporte de Pavilion.

Nuestro objetivo es que el Producto DEIP sea una alternativa viable a la gestión de eventos en plataformas de comunidad propietarias y que la Especificación y el Prototipo DEIP impulsen los esfuerzos en la estandarización del modelo de datos de eventos de calendario.

Modelo de Negocio (Explotación comercial)

Pavilion ha desarrollado un modelo de suscripción para nuestros plugins de Discourse de código abierto que mantiene nuestros compromisos con el código abierto y el apoyo a comunidades sin fines de lucro, al tiempo que garantiza que nuestros miembros reciban una compensación adecuada por su trabajo. El modelo tiene las siguientes características:

  • Código 100 % de código abierto.
  • Características «empresariales» seleccionadas que no son visibles en el cliente de la aplicación a menos que el administrador de la comunidad haya comprado una suscripción.
  • Suscripciones gratuitas para comunidades sin fines de lucro que utilizan las características «empresariales».
  • Servicios orientados a empresas para suscriptores de pago.

La restricción de características en una base de código 100 % de código abierto puede superarse programáticamente; sin embargo, esto no es relevante para el mercado objetivo de las suscripciones de pago. Las empresas quieren pagar por servicios que les beneficien, y aquellos que eligen superar las restricciones no son los clientes objetivo para ese aspecto del producto.

Podríamos ampliar potencialmente el alcance de este proyecto para incluir algunas de las otras cosas que has mencionado, es decir, aquellas centradas en las características de eventos dentro del propio Discourse; sin embargo, necesitaríamos financiación adicional. Si deseas discutir esto más a fondo, puedes enviarme un mensaje privado al respecto. En cualquier caso, compartiré más detalles sobre el proyecto DEIP aquí en meta a medida que avancemos.

10 Me gusta

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

8 Me gusta

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

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

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

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

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

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