Newer
Older
# Events
### Eventverwaltung über die Website
Um Events auf der Website darstellen zu können werden Events aktuell im Repository der Website angelegt.
Wie [fast alles auf der Website](https://git.chaotikum.org/chaotikum/website/-/blob/master/docs/content/content_basics.md) ist auch ein Event in erster Linie eine korrekt formatierte Makrdown-Datei im korrekten Ordner. Der Ordner ist in diesem Fall, wenig überraschend, [`_events`](https://git.chaotikum.org/chaotikum/website/-/tree/master/_events).
Wie ebenfalls vieles auf der Website interagiert dies mit verschiendenen Bestandteilen der Website und wird an unterschiedlichen Stellen integriert. Dafür gibt es neben den recht offensichtlichen Informationen wie einem Titel, Start- und Endzeit und dem Ort einen haufen, teilweise wenig offensichtlicher Flags, die im folgenden erklärt werden.
Für Events die anderen events, die es bereits gab, sehr ähnlich sind, ist es vermutlich oft eine gute idee einfach die entsprechende Markdown-Datei zu kopieren, dort sollte ja hoffentlich bereits alles stimmen.
### Dateinamen
Events werden, anders als z.B. Blogposts, so benannt, dass das Datum zwar zu Anfang steht, aber kein Bindestrich dahinter ist. Das gilt für so ziemlich alles außer Blogposts und hat etwas mit jekyll internen Sortier-Automatismen zu tun, die greifen, wenn jekyll mit Bindestrich getrennte Daten sieht. Ein Dateiname sieht also z.B. so aus:
Diese Dateien werden zu ICS-Dateien verarbeitet. Es ist daher **zwingend notwendig hier nur einen einfachen ASCII Datensatz zu nutzen. Jegliche Unicode-Symbole zerstören das ical parsing und der gesammte Chaotikum-Kalender funktioniert für alle Menschen, die ihn abonieren, nicht mehr**
### Inhalt einer Event-Datei
Eine Even-Datei besteht ausschließlich aus Front-Matter, die beiden Striche am Anfang und Ende sind also wichtig, sonst funktioniert die Verarbeitung nicht.
```
---
layout: [eventcal]
title: "Freitalk: Feinstaubsensoren"
eventdate: 2019-05-10 20:00:00 +0200
eventend: 2019-05-10 23:00:00 +0200
#https://www.uuidgenerator.net/
locations:
- Augenprüfraum
short: "Freitalk N8: Freitalk Nacht - Freitag nach Acht."
---
```
* `layout` MUSS immer `[eventcal]` sein. Die Eckigen klammern sind wichtig, da wir hier als Layout eine nicht html-Datei nutzen (Kalender sind ics), und jekyll das eigentlich nicht mag...
* `title` ist der Name des Events wie er im kalender und überll dort, wo das Event angezeigt wird (z.B. in Aktivitäten und Blogposts) genannt wird. Häufig werden Präfixe wie "Bits und Bäume" oder "Freitalk" vor Events getan, die zu einer Reihe gehören. Das ist aber nicht pflicht. Ein Titel an und für sich ist pflicht.
* `image` Ein veraltetes Feld, wird nicht genutzt, kann man angeben oder weglassen. Sollte mal irgendwo als HEader image landen... das ist aber unsinn. Findet sich noch in älteren Event Dateien. Gerne nicht verwenden.
* `eventdate`: Startzeit des Events. **ACHTUNG. im Winter mit +0100 und im Sommer mit +0200**
* `eventend`: Endzeit des Events. **ACHTUNG. im Winter mit +0100 und im Sommer mit +0200**
* `uid`: Wie [fast alles auf der Website](https://git.chaotikum.org/chaotikum/website/-/blob/master/docs/content/content_basics.md) braucht auch jedes Event eine eindeutige ID. Und zwar eine UID. **Diese UID wird als die im ical format verpflichtende eindeutige ID eines Events genutzt. Ist sie also nicht eindeutig (z.B. durch kopieren einer Datei) kann dies dazu führen, dass Kalendersysteme den Kalender nicht mehr parsen können und der Chaotikum-Kalender für Menschen nicht angezeigt wird. Dies ist also wichtig!** Ändert man einen termin grundlegend (anderes Datum o.ä.) kann es hilfreich sein die uid zu erneuern, damit Kalender besser aktualisieren. **Wichtig: Beachte, wo du die ID sonst noch als verweis zum Event angeben hattest, z.B. Blogposts**.
* `contact`: Jedes Event braucht einen Kontakt. Das ist eine E-Mail Adresse. Per default kann die Adresse des Chaotikum Vorstands genutzt werden.
* `organizer` Menschenlesbarer Namen für die Gruppe, die das Organisiert. Per default Chaotikum e.V.
* `poster`: Ein veraltetes Feld, wird nicht genutzt, kann man angeben oder weglassen. War mal gedacht für Poster. Findet sich noch in älteren Event Dateien. Gerne nicht verwenden.
* `recording`: *true* oder *false* hierbei geht es darum ob wir das Event aufzeichnen, also eine Videoaufzeichnung machen. Das muss nicht unbedingt durchgehend passieren, aber ein Aufbau des Setups oder die präsenz vieler, oft laufender, Videokameras ist zu erwarten.
* `fotopolicy`: Interagiert zu einem gewissen grad mit dem `recording`-Flag. Hier legen wir die Foto-Policy fest. Es gibt Werte: *open*, *restrictive*, *refered* und *ccc*. Die Details unten in einem Abschnitt zur Foto-Policy. Man kann es auch freilassen. Dann greift ein Default. Bei Events mit recording *true* ist der default *open*, bei recording *false* ist der default für die fotopolicy *restrictive*. Entsprechend wird ein Text in der *Eventbox* (s.u.) angezeigt.
* `fotopolicylink`: Wenn `fotopolicy` auf *refered* gesetzt ist, kann hier ein Link zur fremden Policy gesetzt werden.
* `stream`: Manchmal machen wie vielleicht einen Stream. Wenn man sie kennt kann man hier die URL des Streams hinschreiben. Das kommt dann auch in die *Evenbox*. Wir nennen das dann einen *Vielleicht-Stream*, weil es in der Vergangenheit zu irritationen geführt hat, wenn wir, aus welchem Grund auch immer, dann doch keinen Stream machen. Wenn es kein Stream gibt, das Feld einfach leer lassen.
* `stream_certain`: Wenn wir uns sicher sind, dass wir einen Stream machen, kann man hier den wert *true* setzen, dann wird aus einem *Vielleicht-Stream* in der *Eventbox* ein *Live-Stream*.
* `locations`: Eine Liste von Locations. Das sind letztendlich freitexte, aber nur bei bestimmten Raumnamen greifen Automatismen, wie z.B., dass gewisse Kalender für diese Locations gefüllt werden, oder das gewisse Locations zusammengefasst werden können. Werden *Augenprüfraum*, *Wartezimmer*, *Lager* und *Confy Zone* angegeben fasst die öffentliche kalender Datei dies einfach als *Nobreakspace* zusammen. Andererorts verbleiben alle vier Locations.
* `devices`: Eine Liste, mit uuids von Sachen aus dem Inventar, die dann durch dieses Event gebucht werden.
* `short`: Eine kurze Beschreibung. Der iCal standart macht lange Texte anstrengend. Fasst euch bitte kurz. Für lange Texte gibt es den Blog oder Aktivitätsbeschreibungen.
* `series`: ermöglicht es klarzumachen, dass das event zu einer Reihe gehört. Das hat auswirkungen auf die Darstellung in der *Eventbox*.
Mithilfe gleicher uuids kann ein Blogpost das Event finden zu dem er gehört und dann einen Kasten mit den Daten zum Event unten im Blogpost anzeiegn. Wichtig: **Dies geschieht nur, wenn der Blogpost das "tag" "event" hat.**
Die *Eventbox* ist eine Box, welche unten in Blogposts angezeigt wird, in welchen es um ein Event geht. Die enthällt grundsätzliche Daten zum Event, die Möglichkeit ein ical für das Event runterlzuladen und ggf links zum Stream und Infso zu Recording und Fotopolicy. Damit diese angezeigt wird, muss das Event vom Blog-Post aus referenziert werden. Wie das steht, kann man im Kapitel zum [anlegen von Blog-Posts](/newpost.md) nachlesen.
### Foto-Policy bei Events:
Es gibt drei verschiedene Foto-Policies, die gesetzt werden können. Diese Führen zu folgenden texten in der Box:
- *open*: "Unsere Events werden fotografisch und ggf. filmisch dokumentiert. Durch Teilnahme an den Veranstaltungen gilt eine Einwilligung zur Verarbeitung des entstandenen Materials als erteilt. Die Aufnahmen verwenden wir für die Öffentlichkeitsarbeit (z.B. Social Media) und der Dokumentation der Vereinsarbeit (Art. 6 Ab. 1 f DSGVO). Weitere Informationen und Kontaktdaten finden sich in unseren <a href="https://chaotikum.org/datenschutzerk/">Datenschutzhinweisen.</a></b>"
- *restrictive*: "Das Fotografieren und Filmen auf dieser Veranstaltung ist lediglich mit explizieter Erlaubnis aller fotografierten oder gefilmten Personen gestattet."
- *refered*: "Es gilt die Foto-Policy des Veranstalters."
- *ccc*: Ist eine speziell für das camp 2023 erstellte policy, sie verweist auf die dort geltende Policy. Sie müsste angepasst werden, wenn wir sie erneut nutzen wollen...
Wie oben beschrieben, kann man das Feld weglassen, es greift dann ein default über das Flag `recording`. Lediglich, wenn man das nicht möchte, kann man es explizit setzen. Ist recording *false* und die fotopolicy *open* so wird ein Hinweis "Es findet keine kontinuierliche Aufzeichnung, vergleichbar mit einem Vortrag o.ä., statt." hinzugefügt, um vwerirrungen zu reduzieren, das kann man z.B. hier im [Blog-Post über das Sommerfst 2024](https://chaotikum.org/blog/2024/03/25/maifest/) sehen.
Mit dem Wert *refered* verweist man auf die Fotopolicy eines anderen Veranstalters, das ist sowohl nötig als auch nur dann OK, wenn es eine externe Veranstaltung ist, bei der wir den Raum nicht kontrollieren. Zum Beisiel das HanseKulturFestival. Man kann dann einen `fotopolicylink` setzen. Dieses Feld wird bei allen anderen Werten für `fotopolicy` ignoriert.
Die exakte Formulierung der texte in der Box mag sich ab und zu ändern, ggf wird die Doku nicht immer aktualisiert. Der Code zur Darstellung der Texte findet sich in `_includes/post-event.md`. Dort kann das immer nachgelesen werden. Jede Änderung dort wirkt sich auch Rückwirkend auf alle alen Blogposts aus!
### Verarbeitung der Datein
Die hier eingegebenen Datein werden an verschieensten Stellen verwendet. Events werden häufig referenziert. z.B.:
- verschiedne ical Dateien (sowohl pro locatation als auch interne und externe kalender, diese sind z.B. Grundlage für Bots im Matrix Chat)
- verschiedene RSS Dateien, welche wiederum z.B. auch auf Mastodon landen
- frab/schedule.xml (Die Dateien die man für CCC-Events und media.ccc.de uploads braucht)
- Porjekte/Aktivitäten
- Darstellung von Medien/Videos auf unseren Websites
- Reservierung von Geräten und den entsprechenden darstellung im Inventar, der Werkstattseite
- Auf dem Verleih-Formular
Daher ist hier eine gewisse Vorsicht geboten. Insbesondere **bitte immer darauf achten eine frische UUID zu nutzen**, weswegen dies auch [beim Build nochmal geprüft wird]() (**TODO: MISSING LINK**).
### Events generieren
Z.B. am Anfang eines Jahres kann es sinnvoll sein ordentlich mal events zu genrreien. Dazu gibt es ein Skript. Mehr dazu im kapitel [Event-Generator](docs/scripts/event-gen.md).