Der „Mechanical Turk“, auch bekannt als „Schachtürke“, war eine berühmte Erfindung des 18. Jahrhunderts, die als einer der ersten Schachcomputer galt. Gebaut wurde diese vermeintliche Maschine im Jahr 1770 von Wolfgang von Kempelen, einem österreichischen Hofbeamten, um die Kaiserin Maria Theresia zu beeindrucken. Auf den ersten Blick erschien der „Mechanical Turk“ als eine lebensgroße Figur in türkischer Tracht, die vor einem Schachbrett und einem Kasten saß. Das Publikum war fasziniert, als diese Maschine fähig schien, Schach gegen menschliche Gegner zu spielen und oft zu gewinnen. Tatsächlich verbarg sich jedoch ein menschlicher Schachspieler im Inneren des Apparats, der die Züge steuerte. Diese Täuschung blieb für viele Jahre ein gut gehütetes Geheimnis. Der „Mechanical Turk“ tourte durch Europa und Amerika und spielte gegen berühmte Persönlichkeiten, darunter Benjamin Franklin und Napoleon Bonaparte. Der „Mechanical Turk“ blieb bis zu seiner Zerstörung durch ein Feuer im Jahr 1854 eine beliebte Attraktion und wird heute oft als ein frühes Beispiel für die Verschmelzung von Technologie und Illusion betrachtet.

Heute ist der Begriff eher geläufig im Kontext von „Amazon Mechanical Turk“, einer Onlineplattform des gleichnamigen Versandhändlers, auf der gegen meist viel zu geringes Entgelt Menschen weltweit simple „Microtasks“ abarbeiten können, quasi „Heimarbeit 2.0“. Auch Amazons System durchaus fragwürdig ist hinsichtlich Mindestlohn und Arbeitnehmerrechte, ist im Grunde eine Distribution von komplexen Aufgaben in eine größere Crowd hinein doch durchaus sinnvoll – ganz besonders im unterfinanzierten Kulturbereich, wo es stark auf die Leidenschaft und ehrenamtliches Engagement ankommt.
In unserer täglichen Chor- & Orchesterarbeit bei ORSO Berlin e.V. prasseln täglich Aufgaben auf uns ein, die wir als kleines Team unmöglich alleine schaffen würden. Es muss also sehr viel kommuniziert, immer wieder abgesprochen und nachgefasst werden, wer bis wann was auf welche

Weise übernehmen könnte – ohne passende Software nahezu ein Ding der Unmöglichkeit und meist mit viel Reibungsverlusten und nervötendem Orgaaufwand verbunden.

Die meisten Tools sind leider entweder zu simple oder aber oft sehr schwerfällig, zu kompliziert, „unsexy“ oder schlicht zu teuer. Open-Source-Produkte gibt es zwar, erfüllen aber den Zweck nicht wirklich oder die Einstiegshürde für die Anwender ist zu hoch oder die Lernkurve für Organisatoren zu steil. Und sie lassen alle Eines vermissen: Eine Art „virtuelles“ Belohnungssystem, ein Spaßfaktor der Lust macht, das System zu nutzen, quasi ein kleines bisschen von einem “Dopamin-Kick”.

Im Zusammenhang von Kulturbetrieb und Ehrenamt sprechen wir von wichtiger, wertvoller und oft sehr umfangreicher ehrenamtlicher Arbeit, die nicht i.d.R. nicht vergütet wird. Dennoch ist es wichtig und richtig, wenn über das Geleistete quasi „Zeugnis“ abgelegt werden kann. Das kann ein witziges Punktesystem, eine fiktive „Währung“ oder Ähnliches sein. In jedem Fall kann es eine spielerische Art und Weise sein „DANKE!“ zu sagen. Dies unterstützt (nicht nur) Kulturinstitutionen, die eigene Fangemeinde, Helfer und Helfers Helfer „bei der Stange zu halten“ – vom praktisch-technischen Nutzen einer sinnvollen Arbeitsverteilung mal ganz abgesehen.

Jedem Verein, Ensemble oder sonstigen Gruppierung ist es natürlich dabei selbst überlassen, ihren Dank letztendlich zum Ausdruck zu bringen: Gesammelte „Rewards“ eines Ehrenamtlichen können beispielsweise in ein Goodie wie Freikarten, kostenlose Infrastrukturnutzung, exklusive Events oder ähnlichs eingetauscht werden. Und ein „Highscore“ Dashboard ist einfach auch spaßig und sorgt für eine gewisse Dynamik und augenzwinkender Wettbewerb innerhalb der Community.

Schon bei mehr als 20-30 Ehrenamtlichen verliert man als Vorstand oder Eventorganisator schon mal über die Monate eines Projektes den Überblick, wer hat eigentlich was wo wie gemacht, sich wie stark in das Projekt eingebracht. Für Ehrenamtliche wiedrum ist es wichtig, gesehen zu werden und wertgeschätzt zu werden.

Diese Zahl ist nicht aus der Luft gegriffen, sondern entspricht in etwa der Anzahl Todos, die bei ORSO beispielsweise für ein Live-Konzert in der Philharmonie Berlin anfallen. COMET soll all diese Schritte erfassen wie eine gewöhnliche Todo-Liste auch. Zusätzlich soll aber die Möglichkeit bestehen, diese Aufgaben – wo sinnvoll – auf kleinste „atomare“ Mikrotasks runterzubrechen. Diese Mikrotasks sind in Kategorien zu unterteilen, mit Aufwandsschätzungen und Angaben zu notwendigen Vorausetzungen (Führerschein, Sprachkenntnisse, EDV-Kenntnisse, körperliche Voraussetzungen, etc.) und natürlich den „Rewards“ zu versehen.

Dabei soll der Erfassungsaufwand so gering wie nur irgendmöglich ausfallen und kann teilautomatisiert werden, damit „der Crowd“ also quasi den „Turkers“ so möglichst frühzeitig und viel an kleinen, leicht zu erfassenden und zu erledigenden Todos zur Verfügung steht.

Seite 2 von 5

Echtzeit-Kommunikation in alle Richtungen an jedem Vorgang

Nun steht das Akronym “COMeT” nicht allein nur für obige Bezeichnung oder soll an Himmelskörper aus Eis, Staub und Gesteinsmaterial erinnern, nein: In der Welt der Softwareentwicklung und der Web-Technologien bezieht sich „COMET“ auf eine Webanwendungstechnik, die es ermöglicht, dass ein Webserver kontinuierlich oder bei Bedarf Daten an den Client sendet, ohne dass der Client explizit danach fragen muss. COMET steht für „COMet with Extra Toppings“ und ist eigentlich kein offizieller Akronym, sondern eher ein spielerischer Begriff. Es beschreibt ein Modell, bei dem der Server eine offene Verbindung zum Client aufrechterhält, um Echtzeitdaten zu übermitteln. Dies ist nützlich in Anwendungen, wo Echtzeit-Updates wichtig sind, wie beispielsweise bei Online-Chat-Systemen, Live-Feeds in sozialen Netzwerken oder bei Börsentickern. Im Gegensatz zum traditionellen Webanforderungsmodell, bei dem der Client (z.B. ein Browser) eine Anfrage an den Server sendet und auf eine Antwort wartet, ermöglicht COMET eine dynamischere und interaktivere Kommunikation. Es gibt verschiedene Implementierungsansätze für COMET, einschließlich Long Polling, Streaming und WebSockets. Jeder Ansatz hat seine eigenen Vor- und Nachteile, aber das Hauptziel bleibt gleich: eine effiziente, bidirektionale Kommunikation zwischen Client und Server zu ermöglichen, die für den Benutzer nahtlos und reaktionsschnell ist.

Diese Webanwendungstechnik – wir planen hier momentan die Implementierung von Websockets – ermöglicht nicht nur reaktionsschnelles Croudsourcing wie Aufgabenteilung sondern auch die implentierung von Livechats. Chatfunktionen sind unerlässlich für eine reibungslose Kommunikation, bei der man nicht wieder COMeT verlassen möchte um dann weiter in Signal, Whatsapp oder andere Messenger oder noch schlimmer – per Email Absprachen zu treffen. Im Zuge der ARPA 2.0 – Entwicklung bin ich bereits über SignalR gestolpert.

SignalR ist eine Open-Source-Bibliothek für ASP.NET, die es Entwicklern ermöglicht, Funktionalitäten für Echtzeitkommunikation in Webanwendungen einzubauen. Es wurde entwickelt, um die Komplexität zu reduzieren, die mit der Implementierung von Echtzeitfunktionen wie WebSockets, Long Polling und Server-Sent Events verbunden ist. Es ist besonders nützlich für Anwendungen, die schnelle, bidirektionale Kommunikation zwischen dem Server und den Clients benötigen.

Für die UI im Frontend setzen wir weiter auf das Angular Framework unter Verwendung der PrimeNG-Library. Diese Library hat bereits im ARPA-Projekt gute Dienste geleistet um für ein einheitliches und intuitives Look- & Feel zu sorgen. Das Backend wird in C# in einer .NET-Umgebung entwickelt, ebenfalls bewährt in ARPA.

Doch hier kommt ein Aspekt der Selbstbefähigung meinerseits ins Spiel: War ich beim Förderprogramm von ARPA nahezu komplett auf das Frontend und der Sprache Typescript (Angular Framework) focussiert und konnte eine Menge da lernen, soll nun die Reise Richtung Full-Stack-Developer gehen.

Ich möchte die COMeT-Förderung dazu nutzen, tief in C# und Backendentwicklung sowie die Implementierung von SignalR und Websockets einzusteigen um künftig fähig zu sein, sowohl ARPA als auch COMET eigenständig sowohl im Backend als auch Frontend (full-stack) weiterentwickeln, warten und optimieren zu können.

Diesesmal sind wären wir – im Gegensatz zum Großprojekt “ARPA”- nur ein kleines Team von drei Entwickler*innen:

Mira Gutmann ist Full-Stack-Entwicklerin bei Haufe in Freiburg und langjähriges Mitglied von ORSO im Chor. Sie hat nicht nur eine sehr gut Altstimme sondern hat ARPA mit angestoßen und maßgeblich entwickelt und betreut ARPA in ihrer Freizeit ehrenamtlich fast jeden Tag.
David Da Silva ist Front-End-Entwickler, lebt in Lissabon und betreut ARPA seit fast 2 Jahren ebenfalls in seiner Freizeit mit.
Beide Entwickler*innen werden zudem regelmässig von mit “gebucht” als meine Coaches und Berater*innen. Für die Entwicklung von COMeT plane ich externe Leistung von diesen beiden Kolleg*innen einzukaufen. Wir haben festgestellt, daß wir zu dritt am effektivsten sind und stehen quasi täglich via Slack im Kontakt und deployen auch mal mitten in der Nacht neue Features für die Konzertproduktion am nächsten Tag und sie stehen an meiner Seite, wenn chatGPT mir mal nicht weiterhelfen kann.

Für den gesamten Entwicklungsprozess setzen wir nach wie vor auf das CI-Prinzip: Continous Integration, wozu wir Production-Pipelines auf Azure laufen haben. Der Code wird analog zu ARPA ebenfalls auf Github unter einer Open-Source-Lizenz frei vergügbar sein. Ganz nach dem prinzip: gefördert durch öffentliches Geld = öffentlicher Code. Der Code von COMeT wird auch nach Projektende weiter gepflegt und entwickelt und wir suchen dafür wie bei ARPA auch, weitere Mitstreiter*innen weltweit.

Gehostet werden kann das System – wie ARPA auch – auf jedem Rechner (von RaspberryPi mit Linux über Windows-PC oder Mac-OS bis Synology Server, etc.), gegebenenfalls unter Verwendung von Docker-Containern. Derzeit arbeiten wir daran ARPA noch weiter zu optimieren um auch Laien die Dockeranwendung “schmackhafter” und das Deployment einfacher und verständlicher zu machen.

COMeT soll für sich allein deployed werden können, wird aber auch als open-source-code in ARPA miteinfließen um dort ebenfalls zur Verfügung zu stehen, zumal es dortdringend gebraucht wird. Doch das stand-alone-Prinzip für COMeT ermöglicht defcato somit jedem die Nutzung des Tools wie bspw. Sozialeinrichtungen oder Sportvereine oder was auch immer – auch wenn es ursprünglich aus der Kulturbranche kommt. Es sind nun mal eben überall Todos zu erledigen und helfende Hände zu koordinieren. Und nicht zuletzt ist es ja auch mal schön, wenn ein Tool aus der Kultur auch in andere Branchen schwappt wo ebenfalls kein Geld für proprietäre Software vorhanden ist.

COMeT erhält – analog zu arpa.orso.berlin – eine eigene Website um sich über das Projekt genauer informieren zu können. Wir haben bereits einen großen Verteiler an tech-affinenn Kulturschaffenden aus dem ARPA-Projekt. Dieser dient uns als Basis für die Öffentlichkeitsarbeit. Wir planen COMeT zusammen mit ARPA (oder als Bestandteil dessen) diesmal noch stärker persönlich und vor Ort zu promoten, was uns während ARPA-Förderung nicht gut gelang, da dies mitten in die Corona-Pandemie viel und somit sämtliche Live-Events entfielen. Wir möchten nicht nur online sondern auch in Person die Tech-Communities erreichen.

a) Zielsetzung

1.) Ein Taskmanager kümmert sich um schnelle, unkomplizierte Verteilung von Tasks/Microtasks einer Kulturinstitution Ehrenamtliche. COMeT kümmert sich um die Verfolgung der Ergebnisse inkl. spielerischem “Belohnungssystem” für ehrenamtliche Arbeit.
2.)

Ein Chatsystem sorgt für reibungslose Echtzeitkommunikation direkt an den Tasks innerhalb der “Turkers” als auch innerhalb der Teams einer Kulturinstitution.

b) Zeitplan

Februar-März
Phase I – Mockups & Prototyping in Figma. Einholen Community-Feedback & Refinement.

April-Juli
Phase II – Entwicklung und Testing von Backend und Frontend. Lernphase Full-Stack-Entwicklung und Einsatz von Websocket-Technologie (SignalR Implementierung)

August-Oktober
Phase III – Iterationsphase mit Feedbackschleifen aus der Community. Zeit für Tests, Korrekturen und Anpassungen aber auch für Deployement-Workshop(s) für technsiche Laien in Kulturinstitutionen

c) Förderkriterien

COMeT…
…wird skalierbar, veränderbar und erweiterbar sein und soll gleichzeitig stand-alone verwendet aber auch in ARPA integriert werden.
…ist beispielhaft und kann über den Berliner Kulturbereich hinaus adapatiert werden. Translation-Pipelines (wie schon in ARPA verwendet) ermöglichen zudem die Internationalisierung in beliebige Sprachen – auch im Nachhinein noch.
…ist multifunktional und ermöglicht neben Verteilung von Workload auf größere Gruppen auch die Kommunikation weg von proprietären Messengern.
…erfüllt selbsterklärend den Netzwerkgedanken, siehe oben.

d) Personaleinsatz

Der Personaleinsatz ist äußerst gering: Ich, Wolfgang Roese, entwickle hauptsächlich eigenständig unter Zurhilfenahme von externen Vollprofis: Mira Gutmann und David Da Silva.

e) Öffentlichkeitsarbeit

Der Projektverlauf wird über eine eigene Website sowie in Workshops kommuniziert, das Endergebnis live in der Geschäftsstelle oder gerne auch in der Technologie-Stiftung oder auf der re:publica präsentiert.