Diskussion fortgesetzt von Discourse Calendar:
Das Fedora Project hat derzeit unsere eigene Kalender-Webanwendung, Fedocal. Sie ist reif für ein Update, und ich überlege, ob wir sie durch Kalender in Discourse ersetzen könnten, anstatt die eigenständige Anwendung neu zu schreiben. Dies ist keine Funktionsanfrage, sondern eine Erfassung unserer Anwendungsfälle und dessen, was meiner Meinung nach fehlt, während wir evaluieren, was zu tun ist.
Anwendungsfälle
Ich sehe drei wichtige Anwendungsfälle für Fedocal. Wenn es mehr gibt, lassen Sie es mich bitte wissen, und ich werde sie zur Berücksichtigung hinzufügen.
- Terminplanung. Dies ist bei weitem der wichtigste.
- Leuten die Möglichkeit geben, ihre Verfügbarkeit mitzuteilen. Derzeit bitten wir Personen mit Verantwortung im Projekt, dies für Urlaube einzutragen, aber nur wenige tun es tatsächlich. (Ich persönlich finde es einfach zu umständlich, wenn ich mich daran erinnere.)
- Anzeige von Fedora-Veranstaltungen wie Flock to Fedora, Week of Diversity oder Release Parties. Das tun wir heute eigentlich nicht.
Andere Möglichkeiten
- Wir haben versucht, Fedocal für den Zeitplan der Flock-Konferenz im Jahr 2013 zu verwenden, aber seitdem nicht mehr. Es wäre nett, wenn wir eine Lösung hätten, die das attraktiv und einfach macht.
- Anzeige des Fedora-Release-Zeitplans selbst. Derzeit glaube ich, dass wir dies nur zur Planung der Go/No-Go-Meetings verwenden, nicht tatsächlich für den Zeitplan. Wenn wir dies tun würden, müsste es automatisch von Fedora Project schedules importiert werden, anstatt manuell eingegeben zu werden.
Mängel des aktuellen Discourse Calendar Plugins
Das derzeit hinzugefügte “Events”-System ist für unsere Bedürfnisse falsch. (Es sammelt “Events” aus Beiträgen im gesamten Forum und fügt sie in einen einzigen globalen Kalender ein. Wir brauchen viel mehr als das.)
Meine erste Annahme ist, dass wir uns auf die Erweiterung des “traditionellen” Teils des Kalender-Plugins konzentrieren würden, das einen Kalender in der ersten Antwort auf ein Thema hat, das nur von Antworten auf dieses Thema “gespeist” wird. Es könnte jedoch möglich sein, dass der andere Ansatz – das Sammeln von Events im gesamten Forum – besser wäre. In diesem Fall müssten wir es jedoch erweitern, um mehrere Kalender anvisieren zu können. (Und in diesem Fall wäre es schön, sie in angeheftete Themen einbetten zu können, anstatt sie nur im Hamburger-Menü zu verstecken.)
Daher hier einige Dinge, die wir brauchen würden:
Im Allgemeinen
- Die Kalenderanzeige selbst ist ziemlich rudimentär.
- Sie könnte viel schöner sein
- Sie skaliert oder passt sich in keiner Weise an die Anzeige an
- Sie ist fest auf EU-übliche Montag-Sonntag-Wochen eingestellt
- Sie scheint immer Tage in UTC anzuzeigen, obwohl die Einträge in lokalen Zeitzonen sind, was dazu führt, dass ganztägige Ereignisse in einer lokalen Zeitzone auf dem Kalender zwei Tage umfassen können. (Das Discourse-Team ist sich dieses Fehlers bewusst.)
- Die Monatsansicht zeigt derzeit nur die ersten paar Zeichen der Beschreibung eines Ereignisses. Das ist in Ordnung, wenn der Kalender nur um eine einfache Sache geht (siehe hier in Gebrauch für Fedora Social Hour), aber nicht gut für einen Kalender mit vielen verschiedenen Dingen.
- Derzeit kann die “Feiertags”-Version des Kalenders Farben für Ereignisse zuweisen, tut dies jedoch mithilfe eines programmatisch abgeleiteten Werts vom Benutzernamen. Dies sollte stattdessen pro Ereignis konfigurierbar sein und für alle Kalender gelten, nicht nur für den Feiertagskalender.
- Ich glaube nicht, dass es einen .ical-Feed gibt? Das wäre schön, damit Leute ihn zu ihrem Google Kalender oder Ähnlichem hinzufügen können.
- Nice to have: Möglichkeit, Erinnerungs-E-Mails zu generieren, die an Mailinglisten gesendet werden, nicht nur an Abonnenten. Wir haben noch nicht alle auf Discourse!
- Nice to have: eine persönliche Kalenderansicht, in der man genau auswählt, welche Einträge verfolgt werden sollen.
Anwendungsfall Meetings
- Fedocal hat zwei primäre “Achsen” – die Gruppe, zu der der Kalendereintrag gehört (wie “Rat”), und der Ort (wie “#fedora-meeting”). Das Kalender-Plugin kann eines von beiden tun: Wir können ein Thema “Fedora Council Meetings” oder ein Thema “Fedora Meeting Channel” erstellen, aber die Einträge wären nicht verknüpft. Ich bin mir nicht wirklich sicher, wie das beste Design dafür als Plugin aussehen würde – ich denke, wir könnten etwas UX-Design-Expertise gebrauchen, um darüber nachzudenken.
- Es wäre völlig in Ordnung, wenn die “Gruppen”-Achse Discourse-Gruppen wären, insbesondere weil wir irgendwann bald, ICH HOFFE Discourse-Gruppen mit unserem SSO verknüpfen werden.
- Oder möglicherweise könnte die “Gruppen”-Achse des Kalenders ein Tag sein. Das wäre flexibler und würde für uns funktionieren, da wir eine Gruppen-zu-Tag-Zuordnung für unsere Website-Organisation planen.
- Die “Orte”-Achse ist kurz – wir haben eine Handvoll Meeting-Kanäle, und es reicht wahrscheinlich aus, einen “anderen” Ort für seltene Fälle zuzulassen.
- Kritisch: Das System muss Konflikte auf beiden Achsen verhindern – oder zumindest davor warnen. Das heißt, es kann keine zwei Ratssitzungen zur gleichen Zeit geben, und es kann keine zwei Sitzungen von verschiedenen Gruppen am gleichen Ort zur gleichen Zeit geben.
- außer wenn wir einen Sammelbegriff “andere” haben… also, ich schätze, einige Orte sollten Überlappungen zulassen.
- Die Syntax für wiederkehrende Ereignisse ist etwas seltsam, aber in Ordnung. Wiederkehrende Ereignisse werden jedoch nur als wiederkehrend im Kalendergitter angezeigt (und in der Erinnerung als aktualisiert auf das nächste), nichts weiter. Und es sollte mehr geben:
- Kritisch: Es sollte möglich sein, dass Benutzer Benachrichtigungen für jedes wiederkehrende Ereignis abonnieren, und zwar pro Kalendereintrag.
- Nice to have: eine Konfiguration pro Discourse-Gruppe für die Standardbenachrichtigungen für einen bestimmten Kalender, sodass z. B. Mitglieder der Ratsgruppe standardmäßig Benachrichtigungen für Ratskalendereinträge erhalten.
- Nice to have: Möglichkeit, auch 15-minütige Warnbenachrichtigungen für bevorstehende Meetings zu konfigurieren.
- Wichtig: Es sollte möglich sein, bestimmte Ereignisse als zu überspringend (oder zu einer anderen Zeit stattfindend) zu markieren, ohne das gesamte Ereignis zu ändern.
- Kritisch: Es sollte möglich sein, dass Benutzer Benachrichtigungen für jedes wiederkehrende Ereignis abonnieren, und zwar pro Kalendereintrag.
- Derzeit erfolgt die Ereignisdauer mit Einträgen wie
[date=2021-11-28 time=12:00:00 timezone="America/New_York"] → [date=2021-11-28 time=13:00:00 timezone="America/New_York"]. Das ist mühsam einzugeben und das Ergebnis (2021-11-28T17:00:00Z → 2021-11-28T18:00:00Z) ist nicht sofort ersichtlich. Es wäre schön, stattdessen[date=2021-11-28 time=12:00:00 timezone="America/New_York" duration="1 hour"]zu haben.- Nice to have: Einträge ohne Dauer sollten visuell unterschiedlich sein – und vielleicht nur für “ganztägige” Einträge erlaubt sein.
- Nice to have: Jeder Kalendereintrag (separat für wiederkehrende) könnte einen Link zu einem Thema für Agenda + Notizen haben. Dieses Thema würde nicht automatisch ohne Interaktion erstellt, sollte aber mit einem Klick einfach zu starten sein und nach der Erstellung automatisch verknüpft werden.
Anwendungsfall “Feiertage”
- Der Feiertagskalender sollte auch gruppenbewusst sein. Derzeit gibt es einige Sonderfälle für (Discourse-Site-)Mitarbeiter – das sollte verallgemeinert und konfigurierbar sein, und verschiedene Kalender sollten für verschiedene Gruppen sowie einen globalen Kalender zulässig sein.
- In seiner Standardkonfiguration zeigt der Feiertagskalender nationale Standardfeiertage für jede Person an, deren Gebietsschema konfiguriert ist. Wenn das mehr als, sagen wir, fünf Personen an nicht mehr als zwei verschiedenen Orten sind, überlagert dies alles andere. Discourse hat uns jedoch einen temporären Hack zur Verfügung gestellt, um dies zu verbergen.
- Nice to have: Derzeit erhalten Mitarbeiter ein
Emoji neben ihrem Benutzernamen, wenn sie im Urlaub sind, nur für andere Mitarbeiter sichtbar. Die Sichtbarkeit dieses Symbols sollte konfigurierbar sein. - Nice to have: Konfiguration des anzuzeigenden Emojis zulassen.
- Bonus nice to have: Benutzern ermöglichen, aus einer Liste von Emojis und Gründen für eine bestimmte Abwesenheitszeit (Urlaub, Krankheit, Reise usw.) auszuwählen.
Fedora Events
Eigentlich denke ich, dass das, was wir heute haben, dafür funktionieren könnte. Einige der oben genannten Punkte – schönere und flexiblere Kalenderanzeige, Benachrichtigungen, Farben – wären jedoch nützlich.
Für andere Möglichkeiten
- Der Anwendungsfall für Konferenzpläne ist einfach der Anwendungsfall für Meeting-Pläne, aber sehr intensiv. Manuelle Konfliktverfolgung wird unmöglich. Hierfür könnte eine Achse auf Benutzerebene anstelle einer Achse auf Gruppenebene erforderlich sein. (Sprecher können nicht gleichzeitig an zwei Orten sein.) Und im Gegensatz zu unseren Meetingraum-Orten, die sich seit 15 Jahren kaum geändert haben (außer URL-Updates) und sich wahrscheinlich auch in den nächsten 15 Jahren nicht ändern werden, hat jedes Ereignis seine eigenen Orte.
- Release-Zeitplan-Kalender: Ich denke, dies ist hauptsächlich eine Frage der Automatisierung beim Importieren aus den vorhandenen Zeitplandaten. Das bestehende Kalender-Plugin könnte größtenteils funktionieren, denke ich. Wie bei Fedora Events wären auch hier Farbcodes schön.
