Mit diesem Beitrag möchte ich meine kleine Serie vorläufig beenden. Lehre ist für manche an Hochschulen lästig, für mich aber gehört sie zur Wissenschaft dazu — ich finde sie spannend und so möchte ich auch in Zukunft immer wieder mal Aspekte der Hochschullehre allgemein und für HPC-Anwender im Speziellen zum Thema machen.
Zur Sache
Zugegeben: Dokumentation ist kein Teil der Lehre im engen Sinn. “Dokumentation schreiben” lässt vermutlich an einen ungeliebten Bereich der Softwareentwicklung denken (wozu es auch viele Hinweise und Dokumentation im Web gibt; Beispiel). Mir aber geht es, hier bei der Artikelfortsetzung zur Lehre, um Dokumentation eines System für akademische Anwender. Und das ist gewissermaßen die Fortsetzung der Lehre mit anderen Mitteln: Letztlich schreiben nicht wenige HochschullehrerInnen Syllabi für Ihre Veranstaltungen, damit die Teilnehmenden auch nach Abschluss einer Veranstaltungen nachschlagen können. Ich fand manch gut gemachten Syllabus aus meinen Anfängen (witzigerweise ist die Seite heutzutage auf Englisch) auch später sehr nützlich, wenn ich auf die dort dokumentierten Grundlagen zurückgreifen wollte (beispielsweise zur Prüfungsvorbereitung, wenn es darum geht schnell das Gedächtnis aufzufrischen). Für mich steht die Nützlichkeit solcher Dokumentation also außer Zweifel. Nun aber wirklich zur Sache:
Was und für Wen?
Wie ich bereits angemerkt habe ist es für die Präsentation von Inhalten nicht unwesentlich zu fragen, wer eigentlich im Publikum sitzt. In diesem Fall ist das Publikum hinter einem Bildschirm und ohne direkte Interaktion mit den “Lehrenden”. Und nur auf dem den ersten Blick eindeutig ist die Zielgruppe klar umrissen: Die Anwender unserer Cluster. Die Fragen und Anmerkungen, die als Nutzerfeedback bei uns landen zeigen aber an, dass wir eigentlich drei Untergruppen unterscheiden müssen:
- diejenigen, die einen Einführungskurs besucht haben
- diejenigen, die dies nicht getan haben, aber eine Einführung von kompetenten Kollegen erhalten haben
- und diejenigen, die keinen Kurs besucht haben und gänzlich auf sich selbst gestellt sind.
Ich möchte hier nicht werten. Es ist ohnehin müßig zu erwarten, dass alle Nutzer eines HPC-Systems einen Kurs besuchen (einfach weil es immer Menschen geben wird, die sich ohne Druck/Zwang nicht in fakultative Kurse setzen werden). Gruppe 3 ist eine Minderheit: Einige schaffen es tatsächlich ein beeindruckendes Kompetenzniveau zu erlangen, andere können das System nicht nutzen und erkennen nicht, dass sie ohne großen Aufwand zu Gruppe 1 zählen könnten. Gruppe 2 erlangt mit der Zeit Kompetenz (i.d.R. langsamer als Gruppe 1). Es gibt definitiv auch Fälle in Gruppe 2, bei denen deutlich ist, dass ein Kurs zu folgen besser gewesen wäre.
Eigentlich greift nur für die erste Gruppe der Syllabus-Gedanke: Nachlesen (und die verteilten Folien und Skripte nachvollziehen) kann nur wer zuvor einen Kurs besucht hat. Doch die Dokumentation muss für alle Gruppen da sein.
Welche Form und Tiefe?
Manche HPC-Zentren bieten ein wiki ähnlich dem Unseren an, z. B. die Kollegen in Dresden, Frankfurt oder in Gent (um ein nicht-inländisches Beispiel zu haben). Die Liste könnte ich lange fortsetzen. Wir, in Mainz, bieten natürlich auch ein wiki zur Dokumentation an. Und im Wesentlichen sind dessen Inhalte deckungsgleich zum Einführungskurs zur Nutzung unseres HPC-Systems, zuzüglich einiger Details zu Regularien, Zugriff, fachspezifischer Themen (die wir stets auszubauen versuchen) und einigen Inhalten, die Entwickler betreffen. Was fehlt sind die mit den Einführungskursenen verteilten Beispiele, die Erläuterungen und die vielen Übungen zu konkreten Fragen.
Wir versuchen hierbei eine Informationsmischung aus Dokumentation mit Beispielen zum Batchsystem zu bieten und Inhalte zu den Besonderheiten unseres Clusters mitsamt Filesystem und Regeln bereitzustellen. Hierbei ist klar: Die Dokumentation zum Batchsystem wiederholt nicht die Dokumentation des Herstellers*. Der Fokus liegt bei uns an der häufigsten Jobscript-Parametrisierung und praktischen Anwendungsfällen. Und dennoch ist es nicht möglich jeden Anwendungsfall abzudecken.
Wünsche gab es in der Vergangenheit häufiger insbesondere aus der Bioinformatik: Wir sollten möglichst für jede Software eine Dokumentation bereitstellen. Einen Anlauf habe ich gemacht und auch in der Physik gibt es ein paar Extraseiten (ein Beispiel). Letztlich sind wir auf Feedback angewiesen. Es ist nicht möglich sämtliche Software zu kennen; Benchmarks und Empfehlungen können nicht für jede Software geschrieben werden. Das ist auch unabhängig von der Einführung eines Workflowsystems: Es gibt zu viel wissenschaftliche Software, gerade in der Bioinformatik.
Die eigentliche Form ist trocken und bemüht Missverständnisse zu vermeiden.
Wie gut kann ein wiki sein?
Wahrscheinlich steckt das gelinkte Wiki voller Fehler. Ein Wiki ist prinzipiell kein durch Kollegen lektorierter Text. Es ist ein wiki, stupid! Die Idee, zumindest bei uns, ist, dass die NutzerInnen uns im eigenen und gegenseitigen Interesse auf Fehler hinweisen. Das kommt selten vor. Lediglich durch Anfragen wird ab und an deutlich, dass eine Formulierung unglücklich oder ein Beispiel fehlerhaft ist. Das wiki erlaubt aber auch, dass NutzerInnen Information beitragen. Bezüglich der Systeme kann unsere HPC-Gruppe das nicht erwarten — das ist unser Job. Aber bei der verwendeten Software wäre das schon möglich — und sinnvoll.
Daneben kann man aber auch die Qualität an den Zugriffszahlen ablesen (im Verhältnis zur Zahl neuer NutzerInnen). Da kann ich immerhin sicher sein: Die Nachfrage besteht. Vielleicht lesen hier manche NutzerInnen mit und sind danach mutiger Feedback zu geben: Es würde uns freuen!
++++++++++
- Ich mag hier keine Werbung machen: Vor diesem System war es eines von IBM und bei einer anderen Stelle, die ich hatte, hatten wir ein Community-System verwendet.
Letzte Kommentare