Tagungsbüro: Typische Abläufe

Zurück: Startseite

Die Checklisten gliedern wir wegen des Umfanges aus: Checklisten.

Die Logistik der TN-Anmeldungen ist eine der wichtigsten und v.a. häufigsten Aufgaben, die auf das Tagungsbüro zukommen. Später kommt ggf. auch noch die Logistik der WS-Anmeldung hinzu. Beides ist zusammen in folgendem Schema dargestellt und wird dann ausführlich beschrieben.

Es ist uns wichtig: Jede TN-Anmeldung soll persönlich vom TB zur Kenntnis genommen werden und nur auf persönliche Veranlassung auch bestätigt werden. Daher gibt es keine vollautomatische TN-Anmeldung, sondern nur eine halbautomatische.

Es ist uns wichtig: Wir wollen wissen, wer am Ende bei der Tagung war, als TN oder auch als Team oder sonst wie. D.h. wir erfassen alle TN in der DB, und wir erfassen möglichst auch alle Dozenten, Priester, und das ganze Team.

Wir müssen uns schützen: Leider kommt es praktisch bei jeder Tagung vor, dass TN-Anmeldungen kommen, die wir ablehnen müssen. Die Gründe können z.B. sein:

1. Bei Internationalen Tagungen wird über solch eine Anmeldung versucht, sich missbräuchlich ein Visum für Deutschland zu erschleichen. Es wird auf diese Weise versucht, an eine offizielle Einladung der Christengemeinschaft zu kommen, die Voraussetzung für ein Visum ist. In solchen Einladungen steht, dass wir für alle Kosten, insb. auch für Gesundheit, aufkommen. Dann kommen diese Personen nach Deutschland, lassen sich ihre Zähne reparieren, und wir müssen das bezahlen.
2. Manchmal melden sich Personen an, die mit uns einfach überhaupt nichts zu tun haben. Das sind häufig Anmeldungen aus Indien, Bangladesh usw. Man erkennt sie oft daran, dass in der Nachricht lange Texte stehen, die meist mit Sätzen der folgenden Art beginnen: „Liebe Bruder in Christus, wir lieben uns alle und ich sehr interessant für deine Event…“ Oder man erkennt sie daran, dass sie aus Ländern kommen, wo es keine Christengemeinschaft gibt. Auf der anderen Seite gibt es auch manchmal Anmeldungen aus solchen Ländern, weil es tatsächlich persönliche Beziehungen o.ä. gibt. Im Zweifel schreibt man dem TN eine eMail und fragt mal nach, wie er auf die Tagung gestoßen ist und wie seine Beziehung zur CG ist. Oder man versucht, über die Priester etwas herauszufinden.
3. Schließlich gibt es auch manchmal TN-Anmeldungen von Leuten, die entweder zu jung oder zu alt sind. Auch da erreicht man in der Regel am meisten durch Rückfrage.

Die ganze Daten-Logistik für TN- und WS-Anmeldungen wird wesentlich durch das Zusammenspiel von

1. Anmelde-Status und
2. automatischen Mails

gesteuert.

Was heißt das?

Jede Person in der DB hat immer einen Anmelde-Status. Die Liste möglicher Statusse kann in der Anfangsphase einer Tagung typischerweise so aussehen:

Jeder Status kann passiv oder aktiv sein. Einen aktiven Status erkennt man daran, dass…

1. die Spalte Mail auslösen aktiviert ist,
2. die Art der automatischen Mail angeben ist und
3. ein Nachfolge-Status agegeben ist.

Hat ein TN einen aktiven Status, wird der Cronjob auf dem Server aktiv und erledigt folgendes:

1. Er verschickt an den TN die aktive Mail der angegebenen Art
2. Er setzt den Status des TN auf den Nachfolge-Status

In der Anfangsphase einer Tagung, d.h. wenn die Anmeldungen gerade beginnen, und die Statusse der Liste oben entsprechen, passiert also Folgendes:

1. Meldet sich jemand online zur Tagung an, werden dessen Daten automatisch in die DB eingetragen, der TN erhält den Status a, d.h. die Anmeldung ist eingegangen.
2. a ist ein passiver Status, d.h. der Server wird nicht tätig.
3. Das TB prüft die Anmeldung und setzt, falls der TN kommen darf, den Status auf b, d.h. die Bestätigungsmail soll verschickt werden.
4. b ist ein aktiver Status, d.h. der Server wird tätig. In diesem Fall verschickt er die aktive Mail der Art Best an den TN und setzt anschließend den Status auf v, d.h. der TN ist vollständig bearbeitet.
5. v ist ein passiver Status, d.h. der Server wird nicht tätig.

Grafisch sieht das so aus:

In einer späteren Phase der Tagung, wenn die WS-Anmeldungen freigeschaltet sind, könnte die Liste möglicher Statusse so aussehen:

Jetzt passiert also Folgendes:

1. Meldet sich jemand online zur Tagung an, werden dessen Daten automatisch in die DB eingetragen, der TN erhält den Status a, d.h. die Anmeldung ist eingegangen.
2. a ist ein passiver Status, d.h. der Server wird nicht tätig.
3. Das TB prüft die Anmeldung und setzt, falls der TN kommen darf, den Status auf b, d.h. die Bestätigungsmail soll verschickt werden.
4. b ist ein aktiver Status, d.h. der Server wird tätig. In diesem Fall verschickt er die aktive Mail der Art Best an den TN und setzt anschließend den Status auf ws.
5. ws ist ebenfalls ein aktiver Status. Der Server verschickt entsprechend die aktive Mail der Art WS an den TN und setzt den Status auf v (= vollständig bearbeitet).
6. v ist ein passiver Status, d.h. der Server wird nicht tätig.

Kurz gesagt: der TN erhält in dieser Phase erst die Bestätigungsmail und dann auch noch eine Aufforderung zur WS-Anmeldung.

Grafisch:

Noch später, kurz vor der Tagung, kann über die Liste der Statusse auch noch eine Mail mit wichtigen Informationen zur Tagung verschickt werden. Wir nenne sie Packliste. Dann sieht die Liste möglicher Statusse so aus:

Der Ablauf sollte sich inzwischen selbst erklären, grafisch sieht es so aus:

Sagen wir, wir haben gerade die WS-Anmeldung frei geschaltet. Dann möchten wir zwei Dinge erreichen:

1. Alle bereits angemeldeten und bestätigten TN sollen die Aufforderung zur WS-Anmeldung erhalten.
2. Alle TN, die sich ab jetzt anmelden, sollen die Aufforderung zur WS-Anmeldung erhalten.

Den zweiten Punkt haben wir oben schon beschrieben. Er wird dadurch erledigt, dass die Eintragungen in der Liste möglicher Statusse entsprechend geändert wird.

Für den ersten Punkt muss manuell der Status aller TN von v auf ws gesetzt werden. Das wird…

1. entweder durch den Programmierer erledigt
2. oder durch ein Formular in der GUI, das aber noch zu programmieren ist (Stand: 2. Februar 2025).

Entsprechend, wenn später auch noch die Packliste verschickt werden soll.

Bei jeder Veränderung oder Ergänzung der Liste der möglichen Statusse ist besondere Sorgfalt nötig. Es können richtig blöde Fehler gemacht werden:

• Bei der Abfolge der Statusse wird ein wichtiger Status übergangen. Das bedeutet, dass eine wichtige Mail nicht automatisch verschickt wird.
• Bei der Abfolge der Statusse wird eine Endlosschleift eingerichtet. Ist die Abfolge z.B. , so wird der Status pl nie mehr erreicht, ebenso der Status v nicht, und v.a. werden die Bestätigungsmail und die Aufforderung zur WS-Anmeldung immer wieder neu verschickt - Verärgerung bei den TN ist abzusehen…
• Das Programm ist an dieser Stelle nicht sehr fehlertolerant. Hat man z.B. angekreuzt, dass eine Mail verschickt werden soll, aber keine Mail Art angegeben oder den Nachfolge-Status nicht gesetzt, gibt es schwer voraussehbare Probleme.
• Ebenso ist sicherzustellen, dass es auch wirklich eine aktive Mail der entsprechenden Arten gibt.

Tip: Für diese Arbeiten den Programmierer bitten.

Bei Bedarf können auch neue Statusse angelegt werden. Dabei ist, vor allem wenn es aktive Statusse sind, besondere Sorgfalt geboten, ähnlich wie beim Ändern der Abfolge.

Vor allem bei der Beschreibung des Anmelde-Status war oft die Rede von automatischen Mails.

Die Datenbank prüft regelmäßig für jede Person den Anmelde-Status. Je nach Status verschickt die Datenbank dann eine eMail an die Person und setzt anschließen den Status auf den Nachfolge-Status.

Die automatischen Mails einer Tagung werden in der GUI unter Tagungen –> Mails erfasst. Jede Mail hat dann die folgenden Felder, die weiter unten im Einzelnen beschrieben werden:

• Mail-Art
• Aktuell (= aktiv)
• Betreff
• Text/Anhang: Volljährige
• Text/Anhang: Minderjährige
• Text/Anhang: Ki-Tagung
• Text/Anhang: Ki-Betreuung
• Bemerkung

Jede Mail hat eine Mail-Art, über die sie ggf. vom Server zum Versand ausgewählt wird. Typische Mail-Arten sind:

Bei Bedarf können weitere Mail-Arten angelegt werden. I.d.R wird das im Zusammenhang mit ebenfalls neu angelegten - aktiven - Anmelde-Statussen geschehen.

Mehrere Mails können von der selben Art sein, es kann also z.B. verschiedene Versionen der Art Best (Bestätigungsmail) geben. Genau eine der Mails der selben Art muss aktuell sein - diese Mail wird bei Bedarf verschickt.

Das ist sehr hilfreich, wenn man z.B. 10 Tage vor der Tagung die Zahlungsmodalitäten ändern möchte. Dann hat man eine Bestätigungsmail, in der zur Überweisung des Tagungsbeitrages aufgefordert wird und eine weitere, in der darum gebeten wird, den Tagungsbeitrag bar zur Tagung mitzubringen. Bis 10 Tage vor der Tagung lässt man die erste dieser beiden aktiv, dann setzt man die andere auf aktiv. So kann man den Trubel in der heißen Phase entlasten, da man die beiden Mails lange im Voraus formulieren kann.

Minderjährige Besucher von Tagungen (Stichtag: Beginn der Tagung) brauchen die Einverständnis der Eltern dafür. Das ist der Grund, warum für Minderjährige eine abweichende Mail formuliert werden kann, und warum für diese ggf. auch ein Anhang, nämlich eine Einverständniserklärung, mitgeschickt werden kann. Für Volljährige haben wir nie Anhänge mitgeschickt; und es geht auch nur ein Anhang.

Bei der großen LOGOS-Tagung 2022 hatten wir nicht nur erwachsene und jugendliche TN, sondern auch Kinder. Für die Kinder bis 8 Jahren gab es eine Kinder-Betreuung, für die Kinder von 9 bis 14 gab es eine eigene Kinder-Tagung. Daher gibt es zwei weitere Varianten der Texte und Anhänge: Ki-Tagung und Ki-Betreuung. Die Auswahl dieser Texte nimmt der Server allerdings nicht nach dem Alter vor, sondern nach Gruppenmitgliedschaft (TNKT für TN Kinder-Tagung, TNKB für TN Kinder-Betreuung). Für kleinere und Jugendtagungen können diese Felder getrost ignoriert werden.

Anhänge, die über eins der oben genannten Felder mit den automatischen Mails verschickt werden sollen, müssen vorher auf den Server hochgeladen werden. Zur Zeit kann das nur der Programmierer.

Feld für Notizen des TB, die sonst keine Bedeutung für die Mail haben.

Hilfreich für die Organisation sind auch die Gruppen. Auf einer Tagung gibt es die TN, es gibt Dozenten, Priester, das Team usw. Jede Person kann einer oder mehreren Gruppen zugeordnet werden. Typische Gruppen sind:

Jede Person, die sich online anmeldet, wird automatisch der Gruppe TN zugeordnet. Das TB sorgt nötigenfalls dafür, dass die Gruppen-Zurodnungen stimmen, dass also Dozenten wirklich als Dozenten markiert sind und nicht als Teilnehmer, dass Priester als solche markiert sind usw.

Jede Person kann mehreren Gruppen angehören, jemand kann also sowohl TN als auch Team sein, oder Dozent und Priester.

In der Gesamtliste werden zu jeder Person die Gruppen in der jeweiligen Farbe angegeben, zu denen die Person gehört. Außerdem gibt es für jede Gruppe eine gesonderte Liste. Vgl. dazu die Auswertungen.

1. Der TN meldet sich über das Online-Formular an.
2. Die TN-Daten erscheinen automatisch in der DB, der Status steht auf „a“ (angemeldet).
3. Das TB prüft die TN-Daten. Nötigenfalls werden Unklarheiten abgeklärt. Wenn der TN kommen darf, setzt das TB den Status auf „b“ (bestätigen). Wenn nicht, setzt das TB den Status auf „xx“ (abgelehnt).
4. Das TB prüft auch die Gruppen-Zuordnung und ändert sie nötigenfalls. Das ist z.B. bei Dozenten und Priestern, die sich online anmelden, wichtig.
5. Die DB schickt allen Personen mit dem Status „b“ die Bestätigungsmail und setzt den Status dann auf „v“ (vollständig bearbeitet).
6. Alle Personen mit dem Status „v“ (und nur diese!) erscheinen in der Gesamtliste.

In aller Regel wird man solche TN bitten, sich noch einmal online anzumelden. Fall sie das nicht können oder wollen, kann das TB ihre Daten selbstverständlich auch manuell in die DB eingeben. Wichtig ist dann aber, dass tatsächlich alle relevanten Daten bekannt sind; im Zweifel muss man nachfragen. Den Status setzt man dann auf „b“, damit die Bestätigung verschickt werden kann; falls die Daten noch nicht vollständig sind, setzt man den Status auf „a“ (angemeldet).

Klar, auch das kann passieren - Krankheit oder andere Gründe können dazu führen.

In diesem Fall setzt das TB den Status auf „ab“ (abgemeldet).

Am einfachsten ist es, wenn sich auch alle Dozenten usw. online anmelden. Da sie in aller Regel keine Anmeldebestätigung brauchen, setzt man ihren Status gleich auf „v“ (vollständig bearbeitet).

Manchmal scheint es naheliegend, Daten von Personen wieder zu löschen. Z.B. wenn sich jemand wieder abeldet oder wenn ein Anmeldung abgelehnt wird.

Sinnvoller ist es aber, diese Daten nicht zu löschen, sondern den Status entsprechend zu setzen. So kann man nämlich später rekonstruieren, was der Vorgang war. Man sollte dann in dem Feld „Bemerkung“ ein entsprechende Notiz eintragen, z.B. „TB: wegen Krankheit wieder abgemeldet.“

Trotzdem gibt es auch gute Gründe, Datensätze zu löschen. Doppelt vorhandene Datensätze sind das beste Beispiel. Sie entstehen z.B., wenn der TN seine Online-Anmeldung versehentlich zweimal abschickt, oder wenn er einfach vergisst, dass er schon angemeldet war…

Falls Workshops (WS) stattfinden, zu denen man sich vor Beginn der Tagung anmelden soll, unterstützt die DB das auch.

Was kaum anders geht: Die WSs liegen in aller Regel noch nicht fest, wenn die Anmeldungen zu den Tagungen beginnen sollen. Daher ist eine Anmeldung zu den WSs zusammen mit der Anmeldung zur Tagung nicht möglich. Es muss also eine spätere, eigenständige Anmeldung zu den WSs eingerichtet werden.

Es soll für die TN einfach sein: Die TN sollen sich einfach mit ihrem Namen und ihrer eMail-Adresse zu den WSs anmelden können. D.h. wir können nicht davon ausgehen, dass wir ihnen nach der Anmeldung zur Tagung z.B. eine PIN o.ä. schicken, mit der sie sich dann zu WSs anmelden können. Viel zu oft wäre diese PIN dann vergessen oder aus anderen Gründen nicht verfügbar.

Was uns wichtig ist: Die TN sollen für die WSs eine erste, zweite und dritte Wahl abgeben können.

Was uns noch wichtig ist: Wir vergeben die Plätze in den WSs nicht automatisch und streng nach Eingangsdatum der WS-Anmeldungen, sondern wir teilen die TN vom TB aus in die WSs ein. Dabei berücksichtigen wir nach Möglichkeit auch besondere Wünsche, die TN uns in der Nachricht ihrer WS-Anmeldung schreiben. Da steht dann z.B.: „Ich möchte den WS sehr gerne zusammen mit meiner Freundin Frieda Günther besuchen.“ Inwieweit dabei das Eingangsdatum der WS-Anmeldungen berücksichtigt wird, ist Ermessenssache des TB.

Mit der ganzen WS-Anmeldung verfolgen wir zwei Etappenziele:

1. WS-Wunschlisten: Aus den WS-Anmeldungen mit jeweils 1., 2. und 3. Wahl sollen Wunschlisten hergestellt werden, die das TB etwa eine Woche vor Tagungsbeginn die sehr aufwändige Arbeit, die TN endgültig auf die WSs zu verteilen, so leicht wie möglich zu machen. D.h. es soll für jeden WS eine Liste ausdruckbar sein, aus der ersichtlich ist:
   • Welche TN haben diesen WS als 1., 2. bzw. 3. Wahl angegeben?
   • Welche Alternativen haben die TN jeweils angegeben?
2. WS-Teilnehmerlisten: Nachdem die TN den WSs zugeordnet sind, soll es für jeden WS eine TN-Liste geben, die z.B. dem Dozenten ausgehändigt werden können. Außerdem soll für jeden TN der WS in der Gesamtliste erscheinen.

Alle diese Listen stellt die DB vollständig automatisch her - vorausgesetzt, die Daten sind richtig.

Um die beiden Ziele zu erreichen, sind folgende Schritte nötig.

Jeder WS bekommt eine Nummer der Art WS-04 oder WS-104. Folgendes ist sehr ratsam:

• Sich auf entweder ein- oder zweistellige Nummern festzulegen, also WS-012 oder WS-12.
• Niedrige Nummern um die entsprechende Anzahl von Nullen zu füllen. Also nicht WS-1, WS-2, …, WS-10, WS-11, sondern WS-01, WS-02, …, WS-10, WS-11 usw. Das führt später zu sinnvollen Sortierungen.
• Einmal vergebene WS-Nummern nicht ändern oder neu vergeben. Wird z.B. ein WS nachträglich wieder abgesagt, sollte dessen Nummer auf keinen Fall neu vergeben werden.
• Will man eine Systematik in der Nummerierung haben, sollte man die unbedingt festlegen, bevor die erste WS-Nummer vergeben wird. „Systematik“ heißt in diesem Fall, dass z.B. alle künstlerischen WSs die Nummern WS-10 bis WS-19 erhalten. (Bisher haben wir bei keiner Tagung eine solche Systematik verwendet, und wir haben sie auch nie vermisst.)
• Lücken in der Nummerierung sind kein Problem.

Manche Tagungen haben z.B. vormittags Gesprächsgruppen und nachmittags Aktiv-Gruppen, also etwa künstlerische, sportliche, handwerkliche Workshops. Die DB ist ohne Weiteres in der Lage, beides getrennt voneinander zu behandeln. Das ergibt auch Sinn, denn die vormittäglichen Gesprächsgruppen konkurrieren zwar untereinander, sind aber völlig unabhängig von den nachmittäglichen. Möglich und sinnvoll ist also Folgendes:

• Die Gesprächsgruppen am Vormittag werden mit Nummern der Art GG-13 (für Gesprächs-Gruppe 13), die am Nachmittag mit Nummern der Art WS-06 (für Work-Shop 06) versehen.
• Die Gesprächsgruppen am Vormittag lassen wir als Kategorie A, die am Nachmittag als Kategorie B laufen.
• Für beide Kategorien können die TN bei der WS-Anmeldung eine 1., 2. und 3. Wahl abgeben.

Es lassen sich je nach Bedarf bis zu vier Kategorien, also A, B, C und D verwalten.

Falls es mehr als eine Kategorie gibt, muss das unbedingt vor Beginn der WS-Anmeldung geklärt sein. Es muss nämlich in dem Anmeldeforumular für die Online-WS-Anmeldung berücksichtigt werden.

Solche Kategorien können übrigens auch sehr wirkungsvoll zweckentfremdet verwendet werden, wenn die TN für irgendwelche Aktionen auf der Tagung im Voraus in Gruppen eingeteilt werden sollen. Siehe dazu Hilfreiches.

Sobald die WSs feststehen und veröffentlicht sind, kann die WS-Anmeldung freigeschaltet werden (vgl. Checkliste zu WS-Anmeldungen). WS-Anmeldungen werden, genau wie die TN-Anmeldungen, automatisch in die DB eingetragen. Die Weiterverarbeitung geht teilweise automatisch, teilweise muss sie manuell vorgenommen werden.

Die DB vergleicht jede eingehende WS-Anmeldung mit den TN-Daten. Wenn Name, Vorname und eMail-Adresse übereinstimmen, ordnet die DB die WS-Anmeldung automatisch dem entsprechenden TN zu. Wo das automatisch nicht geht, muss das TB manuell eingreifen.

Typische Gründe, warum die Zuordnung nicht automatisch erfolgt:

• einfache Tippfehler in der TN- oder WS-Anmeldung bei Name, Vorname oder eMail-Adresse
• bei der TN- oder WS-Anmeldung sind Name und Vorname vertauscht
• bei der TN-Anmeldung ist die eMail-Adresse der Eltern angegeben, bei der WS-Anmeldung die des TN (z.B. weil er in der Zwischenzeit eine eigene bekommen hat)
• der TN hat verschiedene eMail-Adressen…
• der TN hat zwar eine WS-Anmeldung ausgefüllt, hat sich aber nie zur Tagung angemeldet

Entsprechend muss das TB…

• die Daten korrigieren (im Datensatz der TN oder in der WS-Anmeldung)
• Rücksprache mit dem TN halten, ihn z.B. auffordern sich auch als TN anzumelden
• je nach Situation auch anders reagieren

Die Korrekturen kann man in der GUI unter Personen → WS-Anm. durchführen, in Einzelfällen muss man auf Personen → Jugend: Einzelheiten zurückgreifen.

WS-Anmeldungen, die kurz hintereinander doppelt eingehen, werde i.d.R. von der DB herausgefiltert. Trotzdem gibt es manchmal von einem TN zwei oder mehr WS-Anmeldungen. Häufig dann, wenn der TN es sich nach der ersten WS-Anmeldung anders überlegt. In solchen Fällen kann man überzählige WS-Anmeldungen einfach löschen.

Leider sehr häufig sind die Einträge bei den WSs in den WS-Anmeldungen eher kreativ als korrekt. Was wir brauchen, ist einfach nur die Nummer, also z.B. WS-05 oder GG-21. Hier eine unvollständige Auswahl, was oft tatsächlich so kommt:

All das muss vom TB manuell korrigiert werden, damit später brauchbare Listen entstehen.

Tip 1: Die Fehler findet man am einfachsten, indem man die WS-Wunschliste durchguckt. Da für jeden WS eine eigene Seite angelegt wird, entsteht auch für jeden Fehler eine eigene Seite. Man sieht sehr schnell, wo die Probleme liegen. Dann muss man die WS-Anmeldungen suchen und korriegieren, das wiederum geht in der GUI am besten unter Personen → WS-Anm.

Tip 2: Hat man die Fehler korrigiert und will das Ergebnis in der WS-Wunschliste überprüfen, will aber nicht lange warten, kann man unter Verwaltung → Reg. Aufg. a. Liste (d.h. Regelmäßige Aufgaben als Liste) die Herstellung sofort veranlassen. Dafür sucht man die Zeile Tagung: WS Wunschliste mit dem Kommando Ta-14-WS-Wuensche.py, setzt das Häkchen in der Spalte Sofort und speichert den Datensatz. (Alle anderen Werte in diesem Formular sind mit Vorsicht zu genießen, vgl. dazu Regelmäßige Aufgaben.)

In der WS-Wunschliste ist auf der ersten Seite eine Übersicht zu sehen, von wie vielen TN bereits WS-Anmeldungen vorliegen. Je nach Verlauf kann man 10 bis 7 Tage vor der Tagung an die TN, die noch keine WS-Anmeldung geschickt haben, die WS-Mail nochmal verschicken. Dazu bitte den Programmierer fragen, denn dafür gibt es bisher kein Formular (Stand 2. Februar 2025).

Je nach Größe der Tagung und Kapazitäten im TB sollte man zwei bis vier Tage vor der Tagung die Daten der WS-Anmeldungen in Ordnung bringen, so dass die WS-Wunschlisten korrekt ausgedruckt werden können. Dieses Dokument ist in DIN-A3 angelegt und sollte auch in diesem Format ausgedruckt werden, sonst hat man es mit sehr kleinen Schriften zu tun.

Sobald die WS-Wunschlisten fertig sind (s. letzter Schritt), sind manuell die TN auf die WSs zu verteilen. Dafür breitet man am besten die WS-Wunschlisten nebeneinander aus und arbeitet zu zweit. Und dann teilt man die TN nacheinander den WSs zu, markiert sie entsprechend auf den WS-Wunschlisten und streicht sie auf den anderen.

Falls es mehr als eine Kategorie von WSs gibt, ist das natürlich für alle Kategorien zu erledigen.

Ist diese Arbeit abgeschlossen, trägt man WS-Nummer(n) in die Datensätze der TN ein. Das geht in der GUI am besten unter Personen → WS festlegen.

Die DB stellt dann zu jedem WS eine TN-Liste her, die ausgedruckt werden und z.B. dem Dozenten ausgehändigt werden kann. Außerdem erscheinen die WS-Nummern in der Gesamtliste in der entsprechenden Spalte.