Webgestützte Zusammenarbeit und "das papierlose Büro"


#1

In einigen der Digitalisierungsdiskurse wird oftmals das papierlose Büro evoziert, eine Arbeitsumgebung in welcher wir Vorgänge derart gestalten, dass die Verbindung zur Papierwelt auf’s Äußerste reduziert wird. Diese würde lediglich für Verträge und ähnlich gelagerte Dokumente hergestellt, welche einer verbrieften Unterschrift bedürfen.

Gleichzeitig finden wir in den eingespielten Methoden der digitalen Zusammenarbeit zivilgesellschaftlicher Initiativen häufig eine Ausrichtung auf die Erstellung von Papiermedien. Dies äußert sich in Text- und PDF-Dokumenten, welche über E-Mail oder Cloudspeicher herumgereicht werden.

Diese Gewohnheit lässt uns gerne die Möglichkeiten übersehen, die wir als digital Natives mit den Vorzügen einer ubiquitär vernetzten Informations- und Kommunikationsinfrastruktur genießen können. Als buchstäbliches Beispiel gilt hinlänglich das World Wide Web, kurz Web. Es wurde konzipiert, um elektronische Resourcen, seien es Dokumente oder heutzutage ganze Anwendungen, mit Hilfe von einheitlich verwendbaren Adressen untereinander zu verknüpfen. Diese Praxis wird auch Verlinken genannt.

Ein papierloses Büro erscheint mir dann eher möglich, wenn wir die ephemeren Anliegen, welche nicht zwingend den Beschränkungen der Papierform bedürfen, mittels webgestützter Informationsmedien erstellt und bearbeitet werden. In der Praxis hat sich eine Kombination von Webwerkzeugen zur Abbildung unterschiedlicher zeitlicher Verwendungsmuster als vorteilhaft erwiesen:

  1. Kurznachrichten zur Befriedigung kurzfristigen, knappen Austauschs
    beispielhaft sei hier Matrix/Riot erwähnt, welches plattformübergreifend (Web/iOS/Android) Nachrichten austauscht
  • Nachrichten…
    • verschwinden mit der Zeit im Scrollback
    • lassen sich direkt verlinken
    • geraten leicht in Vergessenheit oder werden mitunter übersehen
  1. kollaborative Textdokumente zur Erstellung und Entwicklung mittelfristiger Dokumentation
    Links zu sog. Pads werden herumgereicht; zu gegebenen Anlässen gibt es Spitzen der Aktivität
  • Pads…
    • lassen sich direkt verlinken und bleiben langfristig zugreifbar
    • haben ggf. leicht merkbare Adressen und fügen sich wmgl. in ein Adressierungsschema ein
    • sind zudem über Globbing in der Browseradresszeile schnell auffindbar
  1. Strukturierter Diskurs zur Befriedigung mittelfristiger, umfassender Diskussionen
    Der permanente Nachrichtenaustausch lässt manchmal aus einzelnen Themen viele kleinere entstehen; zur klareren Unterscheidung dieser empfiehlt sich die Strukturierung der Diskussion in von einander separate Stränge
  • Diskussionsstränge…
    • können moderiert und ggf. aufgesplittet werden
    • lassen sich im Privaten führen
    • bleiben stets für die Zukunft leicht über einen Link erreichbar
  1. Datenarchiv, Kalender und Kontakte zur langfristigen Dokumentation der eine Organisation betreffenden grundständigen EDV-Bedürfnisse
    Prozesse, die nicht im Web abgebildet werden können, finden hier eine Ablage ihrer Artefakte; dazu Zählen Dateien, Kalender und Kontakte; Texte und Tabellen können rudimentär gemeinsam bearbeitet werden
  • Dokumente, Termine und Visitenkarten…
    • werden hier einem geschlossenen Nutzer:innenkreis zugänglich gemacht
    • überwinden nach expliziter Ablage die persönlichen Silos auf individuellen Geräten
    • können intern und mit Dritten über das Web geteilt werden

Für die letzten beiden Bestandteile einer solchen über das Web als Werkzeug integrierten Kommunikations- und Informationsinfrastruktur experimentieren wir bereits gekonnt mit Nextcloud und Discourse. Nun erscheint es mir ratsam konkrete Strategien zu entwickeln, wie sich diese Nutzung im Rahmen des ‘Solidarische Landwirtschaft e.V.’ durch verschiedene Nutzer:innengruppen vertiefen lässt, und wie die anderen genannten, direkter interaktiven Austauschformen in gemeinschaftliche Gewohnheit übergehen können.

Hier zu zählen

  • die aktive Ausschöpfung der immediaten Austauschform über plattformgrenzen hinweg, die kürzere Wege und direktere Peer to Peer Vernetzung zur Folge hat.
    Einen beispielhaften Kanal gibt es unter https://riot.allmende.io/#/room/#solawi:matrix.allmende.io, andere könnten folgen. Eine eigene Instanz mit eigener Adresse wäre ebenfalls denkbar.
  • die Einbeziehung von web-native Zusammenarbeits- und Veröffentlichung Workflows in die alltägliche Praxis.
    Dokumente und Prozeduren, welche ephemeren Charakter haben und nicht in Papierartefakte münden, können gezielt ausschließlich digital produziert und vorgehalten werden. Geschieht dies mit einer Anbindung an das World Wide Web, sind diese Dokumente transversal mit anderen Austauschformen verbindbar. Unterstützen die gewählten Plattformen zudem das Markdown Markup Format, können Textschnipsel zudem mit der einfachsten Interoperabilitätslösung Copy and Paste bequem von einer Darstellungsform in eine andere überführt werden.

In der Webcrew erstellen wir gegenwärtig aus gemeinsam in Pads geschriebenen Notizen noch PDF Dokumente, welche die Papierform simulieren. Da wir nicht davon auszugehen brauchen, dass diese einstmals gedruckt werden, besteht die Gelegenheit, dass wir eine andere, Markdown-kompatible Langzeitarchivierung in Form eines Wikis o.ä. erdenken. Zunächst würde es mE genügen zumindest eine Ablage für Links zu verwendeten Pads zu etablieren.

Könnte dies in einem wiki-aktivierten Post hier in Discourse geschehen?


#2

Ich finde weiterhin Pads kein geeignetes Format für Protokolle, da Protokolle meiner Ansicht nach nachdem Abnicken des Inhalts durch die Teilnehmenden nicht mehr bearbeitbar sein sollten – zumindest nicht für die komplette Öffentlichkeit. Dies wollte ich mit den PDFs simulieren.

Grundsätzlich bin ich jedoch auch dafür, weg von PDFs zu gehen und hoffe, dass wir in den nächsten Monaten eine WIKI-Lösung am Start haben, über welche gemeinsame Bearbeitung und abschließendes “Sperren” eines Protokolls abbildbar sein wird. Als Zwischenlösung können wir ja nun erst mal deinen Vorschlag bzgl. Wiki-Seite hier im Discourse umsetzen, @yala. Hab das jetzt mal testweise umgesetzt – sollte jemand von euch schwere Bedenken damit haben, möge er sich hier melden.


#3

Hallo Michael,

danke für die Aufsplittung der Konversationen. Ich denke es kann gut sein für Einladungen separate Stränge zu eröffnen, damit einzelne Themenstränge nicht ellenlang und konzis bleiben. Die Einladung zum 10.12. hat mich beispielsweise nicht erreicht.

Auch finden in den Gesprächssträngen oft kleine Nebengespräche statt, die eher einem aktuell stattfindenden Kontext entspringen, als der langzeitbehafteten Ablage von Gesprächen. Wir wollen lieber kurzlebige, kurze Einzeldiskussionen, als endlose, langlebige Stränge in denen sich die Themen vermischen.

Ich habe dies einmal beispielhaft mit

und

durchexerziert.

Wenn du dich mit deinem GitLab Account auf hack.allmende.io oben rechts anmeldest, bevor du ein Pad erstellst, kannst du auch andere Sicherheitseinstellungen vornehmen, siehe hack.allmende.io/s/features#Permissions


#4

Was sind denn Eure Erwartungen an das Wiki? Wer soll damit arbeiten?

Ich habe schon sehr gut und strukturiert mit einem themenbezogenen Wiki gearbeitet (Dokumentation, Termine, AGs etc.) und könnte mir das wieder mal anschauen.


#5

Als einzelne Tools durchzuexerzieren, was mit Sicherheit auch dazu gehört, bin ich eher daran interessiert zu sehen, wie die verschiedenen Kommunikations- und Dokumentationsebenen in einander spielen. Beispiel: Wir erstellen ein Pad. Es dient als Beschlussvorlage für einen Rat oder eine AG, und verwandelt sich bspw. in ein statisches Dokument im GitLab, oder wird eben zu einem Gesprächsstrang in einer speziellen Kategorie.

Andere Möglichkeiten wären dedizierte Kategorien als gemeinschaftliche Kalender:

oder eben auch monoton ablaufende, aber sachliche Konversationen eben wie zur zeitlichen Koordinierung und Protokollierung von Ereigniseen in

Wir haben das alles schon, nur die Reihenfolgen und Ordnungen dürfen uns noch etwas mehr ins Blut übergehen. Dabei auf Markdown als universelle Copy’n’Pase Austauschsprache zu bauen wäre keine dumme Idee.

Später können wir dann auch mit Wikis wie https://growi.org/ (demo) spielen. Noch sehe ich aber keine Glanzleistungen am Markdown-Wiki Himmel, wenn ich ehrlich bin. Dann lieber gute statische Seitengeneratoren per CI/CD verbinden, um via GitLab/Prose.io/Netlify CMS ganze Websites zu Wikis zu machen.


[RFC] Geotagging und Kalendrierung ermöglichen
#6

Für mich gehören u.a. genau solche Themen in die Konzeption des Softwarepakets da solche “Prozessabwicklungen” halt möglichst einfach sein müssen für diejenigen im Netzwerk, die nicht großartig IT-affin sind.
Ich stelle bspw. daher schon grundsätzlich infrage, ob wir in Zukunft tatsächlich weiterhin Pads erstellen werden, oder (zumindest wenn klar ist, dass die Überführung in ein statisches Dokument stattfindet) direkt in einem Wiki (oder einem CMS, welches paralleles Frontend-Editing unterstützt) arbeiten werden. Mit entsprechenden Plugins wäre sowas je nach favorisierte Dokumentations-Lösung ggf. möglich, siehe bspw. Etherpad-Plugin für DokuWiki.

Auch solche Lösungen sollten wir im Rahmen der Softwarepaket-Konzeption mit ins Auge fassen – inkl. dem wichtigen Aspekt, wer die Nutzer*innen der einzelnen Software-Lösungen sein werden.
Bspw. finde ich Markdown ebenfalls super hilfreich, jedoch müssen die Softwares eben auch hier wieder von IT-Laien verwendet werden können. D.h. um (zusätzlich verfügbare) WYSIWYG-Editoren werden wir meiner Ansicht nach nicht herumkommen, wenn wir wollen, dass unsere Lösungen von der breiten Nutzerschicht angenommen werden.