Video und erste Lessons Learned: Der Book Sprint #CoScience geht ins Web und auf der CeBIT weiter
15 eingeladene Autorinnen und Autoren haben sich letzte Woche an der TIB getroffen, um in einem Book Sprint die erste Version des Handbuchs
CoScience – Gemeinsam forschen und publizieren mit dem Netz
zu schreiben. Ab heute ist diese Version online; eine spätere Version soll auch in gedruckter Form erscheinen.
Auf der in dieser Woche stattfindenden CeBIT 2014 geht der Book Sprint nun weiter: Am Messestand der TIB wird das Projekt vorgestellt. Leserinnen und Leser haben die Möglichkeit, im Buch zu kommentieren, Änderungs- oder Ergänzungsvorschläge zu machen – die dann den Hauptautoren der jeweiligen Kapitel vorgelegt werden.
Einige der AutorInnen sind auch auf der CeBIT anwesend; heute (Dienstag, 11.3. um 13:30 in Halle 9) werden sie im Rahmen der Veranstaltungstungsreihe ‘Future Talk’ von ihren Erfahrungen im Bereich des kollaborativen wissenschaftlichen Schreibens berichten und einen Ausblick auf zukünftige Entwicklungen geben.
Wie sieht ein Book Sprint aus, und warum schreiben Autoren mit?
Unser Video fasst erste Eindrücke zusammen. Nächste Woche ergänzen wir noch ein paar Aufnahmen vom CeBIT-Messestand der TIB, so stay tuned!
Book Sprint #CoScience: 4 Lessons Learned
- Bücher, die im Rahmen eines Book Sprints entstehen, benötigen nicht nur Moderatoren (‘Facilitators’), sondern auch Herausgeber. Zur traditionellen Rolle des ‘Facilitators’ bei einem Book Sprint gehört es, zu moderieren und durch den Prozeß des Schreibens und Entwickelns der Texte hindurchzuführen, das Ziel eines in sich stimmigen Buchs vor Augen. Wir haben bemerkt, daß Facilitators auch möglichst vollständig das tun sollten, was z.B. Herausgeber eines wissenschaftlichen Handbuchs tun: den Autoren genau sagen, was sie von ihnen erwarten. Das geschieht am besten in der Form eines detaillierten ‘Author Guides’, in dem festgehalten wird, wie lang die Texte sein dürfen, aber beispielsweise auch, ob die Leser mit Du oder Sie angesprochen werden, wie mit Referenzen und Links umgegangen wird und wer genau die Leserschaft sein soll.
- Für ‘living documents’ benötigt man Versionsverwaltung, für kollaboratives Schreiben Echtzeit-Zusammenarbeit. Man muß es sich wie eine Gangschaltung für zwei Geschwindigkeiten des Schreibens vorstellen. Für die Wochen und Monate nach dem Book Sprint benötigt man zwar ein System wie Github (wie im Fall des Buchs Opening Science, an dem viele CoScience Autoren ebenfalls schon mitgeschrieben hatten) oder MediaWiki (im Fall von CoScience). Solche Systeme ermöglichen zitierbare Versionen eines Buches, das nach der Veröffentlichung gleichwohl korrigiert und weiterentwickelt werden kann. Für die kürzere Phase des Book Sprints selbst benötigt man dagegen Tools zur Echtzeit-Zusammenarbeit wie etwa Etherpad, WriteLaTeX oder Fiduswriter. Für den Übergang vom einen Systemen zum anderen, am besten unter Mitnahme der Versionsgeschichte und Autorenidentitäten, ist uns bisher keine elegante Lösung bekannt.
- Vollständig öffentliche Bearbeitungshistorien sind für wissenschaftliche Dokumente heute noch ungewöhnlich – über die Implikationen sollten die AutorInnen und Bearbeiter vorab miteinander reden. Soll ein Leser, der lange genug im Bearbeitungs- oder Kommentierungsverlauf zurück stöbert, auf eine flapsige Bemerkung oder auf Hinweise zum gemeinsamen Abendessen nach dem Book Sprint stoßen dürfen? Und wenn nicht, will man das durch das Löschen eines Teils der (frühen) Versionsgeschichte, oder durch bestimmte Konventionen verhindern? Auch wichtig ist es dies von Beginn an zu kommunizieren, damit später kein ‘hätte-ich-das-nur-gewusst-Gefühl’ aufkommt.
- Für komplexe Projekte dieser Art benötigt man einen Bugtracker – und eine Kurz-Evaluation. Für die Echtzeit-Zusammenarbeit und zum Entwerfen der Artikel – letzteres machten beim CoScience Book Sprint meist zwei Autoren gemeinsam – wurden wie oben erwähnt Etherpads verwendet. Hier sammelten sich im Projekt CoScience stichwortartige Listen noch offener Punkte und Probleme. Um dies systematischer zu handhaben, z.B. offene Aufgaben zu priorisieren oder sie einem Problemlöser zuzuordnen, wäre es hilfreich, frühzeitig ein für alle zugängliches Bugtracker- oder Ticket-System einzurichten. Darüber hinaus sollte die Book-Sprint-Veranstaltung selbst evaluiert werden, und sei es z.B. mittels Kurzbefragung der Teilnehmenden nach Veranstaltungsende.
Schon jetzt läßt sich feststellen: Unser Book Sprint war überaus herausfordernd und lehrreich. Und er war in mehrfacher Hinsicht erst der Anfang: Sowohl zur Erweiterung des Handbuchs ‘CoScience’ als auch zur Weiterentwicklung und Nachnutzung von dessen Plattform handbuch.io.
Head of TIB Open Science Lab // @Lambo at Mastodon and at TIB
Viel hängt ja auch davon ab, inwiefern das Ziel ist, ein wie auch immer definiertes “Buch” zu produzieren, oder dieses Konzept an sich in Frage zu stellen. Anders gesagt, wie fliesst der Inhalt? Wie wird er gelesen? Darauf gibt es sicher viele Antworten und dazu mehr und weniger geeignete Formate.
Vielen Dank für diese treffende Frage! Vorab: MediaWiki fehlt nicht viel, um sich als Tool zum kollaborativen Schreiben eines Buches zu kümmern – so unsere Einschätzung, und daher ja auch unsere Wahl von MediaWiki als technischer Grundlage. Um dieses wenige, was dabei fehlt, muß man sich allerdings kümmern. Das ist u.a.
1. ein besonders einfacher, strukturierender Einsatz der Erweiterung “Gesichtete Versionen” (siehe meinen Kommentar weiter oben): Leser dürfen kommentieren und vorschlagen, nur die für das jeweilige Kapitel verantwortlichen Autoren dürfen diese Vorschläge akzeptieren. Ein wissenschaftliches Buch braucht kein Crowsourcing-Projekt zu sein (genau dies ist jedoch z.B. bei Wikibooks der Fall), aber wir wollen alle Vorteile des Crowdsourcing, d.h. eine möglichst niedrige Schwelle für jedermann, sich durch stellengenaue *Kommentare* sowie *Änderungsvorschläge* für ein solches Werk einzubringen, abschöpfen. Das ist vielleicht der wichtigste Punkt an diesem Projekt: Die Idee einer Rollenverteilung, bei der Anerkennung und Verantwortung bei einzelnen Autoren liegen, die mit den jeweiligen Herausgebern eine Absprache treffen – also der traditionelle “soziale Vertrag”, der wissenschaftlichen Büchern zugrunde liegt – zu kombinieren mit den Stärken des Crowdsourcing. Wikipedia und Wikibooks sind hingegen “reine”, community-gesteuerte Crowdsourcing-Projekte, mit MediaWiki als der dafür optimierten technischen Grundlage.
eine visuelle Anmutung, die sich von Wikipedia und Wikibooks unterscheiden muß,
2. eine andere Anmutung als Wikipedia und Wikibooks, um den oben genannten Unterschied visuell zu kommunizieren
3. eine noch niedrigere Schwelle zum Schreiben und Kommentieren (d.h. Kommentartool für die Leser, Visual Editor als default für die Autoren), ergibt sich ebenfalls aus dem oben gesagten.
Sowie, noch nicht umgesetzt:
4. automatische Zuweisung einer DOI zu jedem Kapitel für bessere Zitierbarkeit
5. angepasster PDF- und Epub-Output
6. automatische Attributierung der Autoren in den Metadaten der Kapitel.
Vermutlich habe ich jetzt irgendwas vergessen, aber das ist es, so ungefähr.
Um Mißverständnisse zu vermeiden möchte ich bei dieser Gelegenheit nochmal etwas betonen, was gelegentliche Leser meiner Beiträge wohl ohnehin längst wissen: Ich bewundere die Wikipedia. Sie ist in meinen Augen die größte Inspiration für die Schaffung und Vermittlung des wissenschaftlichen Wissens der letzten anderthalb Jahrzehnte. Es gilt, von der Wikipedia zu lernen, und vielleicht kann man auf ihrer Technik und ihren Konzepten einen zukunftstauglichen Prototyp dafür aufbauen, wie Buchproduktion in zehn Jahren aussehen könnte.
Wie man bzw. ihr mit der Plattform tatsächlich arbeitet, kann ich mir noch nicht konkret vorstellen. Vielleicht macht Ihr mal ein paar Videos dazu? Wäre toll.
Da Du die Rolle des Lesers betonst: mir fällt da “Scalar” ein, das Kommentare genauso behandelt wie sonstiger Content auch. Schaut Euch das mal an, falls noch nicht bekannt: http://scalar.usc.edu/scalar/
Was ist eigentlich das Besondere an Eurer Plattform? Inwiefern unterscheidet es sich von einem Mediawiki? Was kann man damit machen, was mit einem Mediawiki nicht geht? Ist es in irgendeiner Weise auf die Leute zugeschnitten, die es benutzen (sollen)?
Oder anders gefragt: wie sehen Eure Anforderungen an ein “Kollaborationstool” (absichtlich so allgemein formuliert) für, sagen wir Sozial- und Geiteswissenschaftler, aus? Habt ihr eine Evaluation vorhandener Tools gemacht?
Ich frage deshalb, weil es gibt ja doch eine Reihe von Kollaborationstools mit einer schier unüberschaubaren Funktionsvielfalt für unterschiedliche Zielgruppen gibt. https://www.google.de/#q=kollaborationsplattform
Ja, ich denke auch, dass es einfach zeitsparender ist und nicht grundsätzlich gegen den selbstorganisierten Prozess spricht, sich schon im Vorfeld Gedanken über Richtlinien zu machen. Die müssen ja nicht vom Facilitator kommen, sondern es könnte jede/r aus der Gruppe damit beginnen. Während des BookSprints bleiben ad hoc noch genug Zweifelsfälle zu klären und die Richtlinien ggf. anzupassen, denke ich.
Das Bild mit den “zwei Geschwindigkeiten” finde ich sehr interessant, und auch die Frage: Wie viel sollen Außenstehende von der Entstehunsgeschichte und der Atmosphäre vor Ort mitbekommen? Gut, das im Vorfeld auszuhandeln.
Zur Weiterentwicklung von MediaWiki: Es gibt von der FH Lübeck eine Autorensoftware auf Mediawiki-Basis, die zwar vornehmlich auf den E-Learning-Bereich abgestimmt ist, aber vielleicht lohnt ja ein Blick darauf? http://loop.oncampus.de/loop/LOOP
Vielen Dank auch für diesen hochinteressanten Hinweis!
Ehrlicherweise hätte ich unsere “Lesson Learned” Nr. 3 noch weiter formulieren müssen: Es stand bei unserem Book Sprint von vornherein auch die Frage im Raum, ob und inwieweit der Sprint selbst in aller (Netz-)Öffentlichkeit stattfindet. Diese grundsätzliche Frage hatte sich bei uns dann dadurch beantwortet, daß an der Plattform selbst sogar noch während des Sprints weiterentwickelt wurde, und zum Teil auch dadurch, daß die AutorInnen sich bewußt aufs Schreiben konzentrieren wollten, statt sich von Diskussionen in sozialen Medien ablenken zu lassen.
Ein spannender Prozess!
Die in Punkt 1 genannten Guidelines muss man als Facilitator vielleicht nicht unbedingt vorgeben, sondern den Teilnehmern helfen, sich schnell auf Grundregeln zu einigen.
Als Plattform zum kollaborativen Schreiben und zur Versionsverwaltung benutzen wir Booktype, was speziell dafür entwickelt wurde. (http://www.sourcefabric.org/en/booktype/) Sicher noch ausbaufähig, aber im Prinzip sehr brauchbar.
Viel Erfolg im Endspurt!
Vielen Dank für den kenntnisreichen Kommentar einer erfahrenen Book Sprint-Facilitadora zu diesem Blogposting!
Zu den Guidelines: Ja, das ist ein interessanter Einwand. Wir hatten im Nachhinein das Gefühl, uns zu sehr auf die Book Sprint-typische Fähigkeit der Autorengruppe zur Selbstorganisation verlassen zu haben. (Zitat eines unserer Book Sprint-Autoren, und das war höchstens zur Hälfte ironisch gemeint: “Ich will hier geführt werden!”) Auch die Erfahrungen von Sandra Schön und Martin Ebner aus dem (virtuellen/verteilten) Book Sprint zur zweiten Auflage des Handbuchs L3T deuten in diese Richtung. (Zitat eines Autors dort: “sagen Sie mir bitte einfach was ich tun soll” – vgl. http://l3t.eu/oer/images/band7_L3T20.pdf)
Vielleicht wird das durch die Erfahrung, Book Sprints als Facilitator zu begleiten, auch besser. Unsere vorläufige Quintessenz lautet: Wir würden den eingeladenen Autoren beim nächsten Book Sprint dieser Art zunächst eine recht detaillierte “Blaupause” eines solchen Author Guides zukommen lassen – mit der Betonung darauf, dass es den versammelten Autoren zu Beginn des Sprints jedoch frei steht, alles über den Haufen zu werfen.
Beim Vergleich von Booktype und MediaWiki waren (und sind) wir hin und hergerissen: Beides sind freie Versionsverwaltungssysteme, die zum kollaborativen Schreiben bestens geeignet sind. So viel steht außer Frage.
Als “Pluspunkte” von MediaWiki gegenüber Booktype haben wir betrachtet, dass einige Details, die beim wissenschaftlichen Schreiben eine Rolle spielen, von Haus aus besser unterstützt werden. Das betrifft insbesondere Literaturreferenzen und das Vorhandensein eines einfachen Qualitätssicherungs-Workflows (Freigabe von Änderungsvorschlägen durch Autoren durch die Erweiterung “Geischtete Versionen”). Zudem gefällt uns das besonders große und vielfältige “Ökosystem” von Entwicklern und Erweiterungen, die uns darauf vertrauen lassen, dass eine Weiterentwicklung von MediaWiki in Richtung “traditionellen” wissenschaftlichen Veröffentlichens besonders vielversprechend sein könnte.
Ein wichtiger “Minuspunkt” von MediaWiki gegenüber Booktype sei aber nicht unterschlagen: MediaWiki kann gewissermaßen “zu viel”. Symptomatisch ist vielleicht, dass wir uns während des ersten Book Sprint-Tags gefragt haben, ob wir ein Buch schreiben wollen, oder ein “Ressourcen-Hub” mit vielen kommentierten Links. (Ergebnis: Ein Buch, denn die WIkipedia gibt es schon, und wir können und wollen keine zweite Wikipedia schreiben.)
Vielleicht sollten wir uns mal darüber austauschen, ob diese Abwägung so korrekt ist, und ob es ggf. Sinn hat, MediaWiki irgendwie Book Sprint geeigneter zu machen. Distraction free MediaWiki, sozusagen. 😉
Schöne Zitate der Sprinterinnen. Das zeigt sicher die Anforderung an den Facilitator, genug und nicht zu viel Freiraum zu lassen – keine einfache Aufgabe.
Was die Frage nach den Plattformen angeht, die das kollaborative Schreiben unterstützen, bringen Sie viele wichtige Vor- und Nachteile auf den Punkt. Für uns steht dabei im Vordergrund, den kollaborativen Prozess simpel zu halten, ihn auf das Wesentliche des Schreibflusses zu konzentrieren, sich an der Struktur eines Buches zu orientieren, auch für wenig technikaffine Mitwirkende einfach handhabbar zu sein, und einfach Aktualisierungen zu ermöglichen.
Bin gespannt, mehr über die Erfahrungen mit MediaWiki zu hören!