¿Hay planes para permitir varios eventos por hilo o por publicación?
Los casos de uso que se me ocurren son:
He encontrado esta limitación al experimentar con un flujo de trabajo de discusión impulsado por el calendario en un foro estudiantil.
Mi caso de uso es que cada evento del calendario se convierte en el ancla de un tema de discusión, en lugar de que el evento sea lo único en el tema.
Por ejemplo, si estoy tratando de programar una reunión con alguien, podría ofrecer varios horarios posibles en el mismo tema de discusión:
• Mar 31 - 12-1 p. m.
• Mié 1 Abr - 10-11 a. m.
• Vie 3 Abr - 3-4 p. m.
Idealmente, me gustaría incluir varios bloques [event] en el mismo tema para que:
• cada hora propuesta aparezca en el calendario del sitio
• los participantes puedan marcarse como asistentes a un horario específico
• una vez que se elige una hora, los otros eventos puedan simplemente eliminarse o editarse
Esto se vuelve aún más útil cuando el tema del evento sirve como hilo de discusión antes y después del evento (agenda, notas, preguntas de seguimiento).
Otro ejemplo de mi foro son las discusiones académicas donde:
• una conferencia
• una hora de consulta
• y una sesión de repaso
todos podrían estar relacionados con el mismo hilo temático, pero siguen siendo eventos distintos en el calendario.
Por el momento, el flujo de trabajo tiende a empujar a las personas hacia un evento por tema, lo que fragmenta la discusión. Permitir varios eventos por tema facilitaría mantener las conversaciones relacionadas en un solo lugar mientras se siguen beneficiando de la integración con el calendario.
¿Puedo proponer un flujo de trabajo alternativo para lograr lo que busca?
¿Qué opina?
Ese flujo de trabajo tiene sentido si el objetivo es simplemente elegir una hora mediante una encuesta.
En la situación que estoy pensando, las horas candidatas se comportan más como eventos provisionales que deben aparecer en el calendario mientras se resuelve la programación.
Por ejemplo, imagina un negocio donde las reservas de clientes crean automáticamente eventos en el calendario. Al mismo tiempo, estamos tratando de organizar un evento social para empleados y proponemos varias franjas horarias posibles.
Esas franjas horarias de los empleados podrían parecer viables inicialmente, pero si aparece un evento de cliente de mayor prioridad y entra en conflicto con una de ellas, esa franja podría necesitar ser eliminada o movida. En ese sentido, el calendario actúa como una vista de programación global, no solo como una forma de elegir la hora más popular.
Por lo tanto, las horas candidatas en sí mismas deben aparecer en el calendario mientras la discusión aún está decidiendo entre ellas. Una vez que se aprueba una hora final, los otros bloques de [evento] podrían simplemente eliminarse o editarse.
Una forma en que esto podría funcionar es si un tema pudiera contener varios bloques de [evento], con uno designado como el evento principal y el resto tratado como eventos provisionales o secundarios. El evento principal sería el canónico para el tema, mientras que los otros simplemente aparecerían en el calendario como franjas horarias candidatas durante la programación.
El evento principal podría ser:
\t• aprobado manualmente (por ejemplo, después de verificar conflictos con eventos de mayor prioridad), o
\t• derivado dinámicamente de una encuesta si la discusión utiliza la votación para elegir una hora.
Por lo que he visto de cómo funciona el complemento, los eventos ya se analizan a partir de los bloques [evento] dentro de las publicaciones y se almacenan como registros separados para el calendario. Eso sugiere que la regla de “un evento por tema” puede ser en su mayor parte una restricción de la interfaz de usuario en lugar de una estructural.
Permitir bloques [evento] en varias publicaciones (con uno opcionalmente marcado como el evento principal) podría preservar el modelo mental actual al permitir flujos de trabajo de programación donde varios eventos provisionales necesitan existir en el mismo tema de discusión.