Open Access Publishing at TUHH: Exemplary Step-by-step guide for a toolchain with TORE, GitLab, Sherpa Romeo and Zenodo

The following step-by-step guide is updated regularly and should be seen as a kind of living document. A more recent version, if available, can be viewed via the repository linked in the license note at the end of the post.

Publishing a paper as preprint would work as described in the following steps:

  1. You have to get an overview on possibilities to publish and open access sharing rights (further information on the websites of the TU library)
  2. Check the permissions of your journal or publisher where you would like to publish via Sherpa Romeo. Example for IEEE proceeding is:
Example for aggregated permissions of IEEE proceedings via Sherpa Romeo

Here you can see that preprints (research papers that are shared before peer review) are possible and which rules you have to follow. For example for CDC (Conference on Decision and Control) you can upload the preprint with a notice that this paper is submitted for review and afterwards you have to place a copyright notice and a DOI link of the IEEE finally published version. You are not allowed to publish the final version, just an author version with the copyright terms. See IEEE policy, section 3 for that.

  1. Create a repository for your publication in our gitlab instance: TUHH – Gitlab (private repo, a public repo can be seen here). In general you create

    • a repository for your paper
    • a repository for your software code (See Code Section)

Use the following scheme: Year-paper-conference-FirstSixWordsOfTitleOfYourPublication (e.g. 2021-paper-ECC-A-Gradient-Descent-Method-for-Finite) while the code is in the corresponding Year-code-TitleOfYourContribution repository.

  1. Have in mind to add references to supplimentary material in the readme.
  2. Add submission or copyright terms to your paper and create a prefinal pdf. You might keep some space (Where??) to place the preprint DOI for references.
  3. Open tore submission page with your personal account (more details via tore help).
  4. Select Publications with fulltext and click on manual submission
  5. The next pages collect metadata:
    • Title
    • Authors (Add an ORCID if possible, Add Prof Werner, for example). Clicking on the magnifier allows searching for entries. Validated entries are marked with a green arrow.
    • Select Language: English
    • Type: Preprint
    • Enter Abstract in English
    • Select TUHH Institute: Type E14 and by using the magnifier select the validated entry.
    • Go next
A click on the magnifier allows searching for entries
  1. Next page collects publisher metadata:
    • These information will be updated with the final version to be submitted for publication
    • Enter Date of issue: Todays date
    • Go next
  2. License details
    • License: Copyright should be selected
    • Supplemented by: Here you can add your Code DOI
    • Project: If you are working for a DFG program, you should reference it here
    • Funder: Here you should add DFG or BMWI as Funder
  3. Now you get your DOI.
    • Copy this DOI into your paper and compile it with this DOI. The DOI is booked but not finally registered. This will be done in the next steps
  4. Now, upload the pdf of your preprint
    • upload pdf
    • check filename (should be meaningful)
    • Set embargo date if neccessary
    • next
  5. Verfiy your submission and accept the license of TORE
  6. Your submission is nearly done. TUHH Library will check your submission. Either they accept it or ask you to change things. You will be emailed. Your entry is so to say, peer review on metadata level
  7. For now you are done. Further version have to be uploaded when the paper got accepted and you can upload the final author version to TORE. Please make sure that you reference the publisher DOI and add the correct credits to the paper.

Publish your software files related to your paper publication

You want to publish files like your source code, your data or videos in a save manner and cite them using a DOI?

The code you publish should be able to reproduce all figures you show in your publication by running one or multiple files which are than related to your figure. If your code uses special software or libraries to run, you should note them down in a dependancies and software section in a readme file of the repository. You should not include these files to your repository. Installation steps should be explained.

Than this is one way to go:

  1. Create a repository for your publication in our gitlab instance: TUHH – Gitlab. In general you create
    • a repository for your paper (See Paper Section)
    • a repository for your software code in (private repo) by using the following scheme: Year-code-conference-FirstSixWordsOfTitleOfYourPublication (e.g. 2021-code-ECC-A-Gradient-Descent-Method-for-Finite) while the paper is in the corresponding Year-paper-conference-TitleOfYourContribution repository.
  2. Upload your code by using git (You can use this repo already when starting to work on an idea: Repositories can be renamed and moved in the gitlab structure). Code should be cleaned up and except for dependancies and libraries selfcontaining. (Be careful on which branch to push, master gets automatically pushed to github, others not)
  3. Add a License file to the repo using templates: GPLv3 (Software) and CC-BY-SA (for all other media) and remove all lines after End of Terms and Conditions around line 625
  4. Add the following header lines to the beginning of each of your files. In references your refere to papers, software or tools you base on to cite them. Make sure that our license in compatible with the build on software/library/code.
% Project: Name and Link
% Copyright: 
% License: 
% References:
% Authors:

% For Paper, 
% "A Gradient Descent Method for Finite Horizon Distributed Control of Discrete Time Systems"
% by Simon Heinke and Herbert Werner
% Copyright (c) Institute of Control Systems, Hamburg University of Technology. All rights reserved.
% Licensed under the GPLv3. See LICENSE in the project root for license information.
% Uses an own implementation of the work of 
% "A. Vamsi and N. Elia, Design of distributed controllers realizable over arbitrary directed networks,
% IEEE Conference on Decision and Control, 2010."
% Author(s): Simon Heinke
  1. You also might want to enter a section in the Readme file on how to cite your work. Therefore you should include bibtex code for citing authors to reference your work in their publication. E.g.:
    Author = {Greg Brockman and Vicki Cheung and Ludwig Pettersson and Jonas Schneider and John Schulman and Jie Tang and Wojciech Zaremba},   Title = {OpenAI Gym},
    Year = {2016},
    Eprint = {arXiv:1606.01540},

Example for from Christian Hespe:

Example for a file
  1. Create a repository at
    • with the same name as in gitlab
    • Give a short meaningful description
    • Select public
    • Click on create repository
    • Ask Lennart Heeren or Patrick Göttsch to grant you maintainer rights in that particular repository
    • Copy the SSH url from github
  2. Enable mirroring in gitlab
    • Switch to your private gitlab repository
    • Left menu -> Settings -> Repository -> Expand Mirroring repositories
    • Paste your github url in Input the remote repository URL
    • Modify it this way: ssh:// at the beginning and replace the colon after with a slash. It should look like this now: ssh://
    • Klick on Detect host keys button
    • Select (although it does not seam to be clickable) in authentification method SSH Public Key
    • And select Mirror only protected branches. By default only the master branch will be pushed as it is.
    • Click on mirror repository to setup the mirror.
    • Now you have to click on the Copy ssh public key
Copy the ssh public key via mousclick on the copy item
  • After a click on the key…
    • go back to GitHub;, click on Settings > Deploy Keys > Add deploy key
    • Give it some title, paste the copied key in the key field and check Allow write access abd than click on Add key
    • Now you can trigger the mirroring by pushing or merging into the master branch in gitlab or manually in the gitlab repo mirroring settings page
  1. Uploading to Zenodo
    • Login to Zenodo using ** Log in with this credentials **
      • user:
      • passwd: JJ^Q?…
    • Click on setting->github (1),
    • Click on Sync now button (2),
    • and enable the repository (3, located at the end of the list),
    • Then we go back to github and create a new release (4):
  • give a version tag like v1.0
  • give a meaningful title
  • and some description (will also be published by zenodo)
  • click on Publish Release
Click on „Publish release“ after assigning a tag, a title and a description

This automatically generates a zip of the code and this zip gets uploaded to zenodo, also automatically.

  1. Creating a DOI/Publishing
  • Back in Zenodo click on upload at the top of the page
  • Here you find your software code already published
Published software code
  • Since not all metadata is available on github, you have to edit your entry
    • Click on the title opens the entry and shows a view as readers would see it.
    • You can click on edit to add or change metadata. The next view is organised in multiple sections:
      • Files: Here you can upload a new version manually. But normmaly you would choose a github release as the way to go.
      • Communities: Please select Hamburg University of Technology to reference this contribution to TUHH
      • Upload Type: Should already be Software
      • Basic Information:
        • Adjust the Title because the github repo name has been used. E.g.: Code for paper: Name of my marvellous paper
        • Authors: Clean up authors list; Lastname, Firstname – Hamburg University of Technology – Institute of Control Systems – ORCID
        • Add Prof Werner to this list: Werner, Herbert Hamburg University of Technology – Institute of Control Systems – 0000-0003-3456-5539
        • Add a meaningful Description
        • Version tag got automatically set
        • Language: Choose English
        • Give similar Keyword as you choose for your paper
      • License: All should be okay. The License is provided in the repository. Zenodo so far does not support GPLv3.
      • Funding: Select nothing
      • Save the changes. And when you think they can be published, hit the publish button.
  1. Cite code
    • use Zenodo Bibtex generator to get a bibtex entry of your code for your latex literature file – Export section (bottom right)
BibTeX code export via Zenodo

Put a DOI patch into the readme -> Use latest version DOI by clicking on the DOI entry (1) and copying the markdown code (2) from the window. You can add a badge to your gitlab repo as well, either in the readme (2) or by adding a batch using (3a) and (3b)

Zendodo DOI Badge

You might want to change the DOI to the DOI for the latest version:

Adjust the DOI
  1. Updating
    • Create new release on github
    • update Description on zenodo
CC BY 4.0
Weiternutzung als OER ausdrücklich erlaubt: Dieses Werk und dessen Inhalte sind – sofern nicht anders angegeben – lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: Open Access Publishing at TUHH: Exemplary Step-by-step guide for a toolchain with TORE, GitLab, Sherpa Romeo and Zenodo von Patrick Göttsch, Christian Hespe, Adwait Datar, Simon Heinke und Lennart Heeren Lizenz: CC BY 4.0. Eine ggf. aktualisierte Version des Workflows kann über dieses GitLab-Repositorium abgerufen werden.
Klemmbausteine Idee

Wie machen wir OER? Einblicke bei tub.torials

Ein Vorteil von offen lizenzierten Inhalten ist, dass Texte und Materialien, die für andere Medien geschrieben oder erstellt wurden, auch selbst veröffentlicht und frei weitergenutzt werden können. Der Blogbeitrag Wie machen wir OER? Einblicke bei tub.torials wurde unter CC BY 4.0 über das Insights-Blog am 15. April 2020 veröffentlicht. Beim Recherchebarcamp 2021 diente dieser als grobe Strukturvorlage für eine spontan angebotene Session zum Thema OER. Die Änderungen des Originalbeitrags werden im Lizenzhinweis (siehe Textende) aufgeführt. Der überarbeitete Beitrag wird zusätzlich in einem offenen Format (Markdown) angeboten.

Was bedeutet OER überhaupt?

Über Open Educational Resources (OER) gibt es viel zu lesen. Kurz zusammengefasst handelt es sich um offene Bildungsmaterialien, die gemeinfrei oder unter einer offenen Lizenz zur Verfügung gestellt werden. Interessierte können das veröffentliche Material kostenlos nutzen, für eigene Lehr-Lerneinsätze bearbeiten und auch weiterverbreiten. Je nach Lizenz mit keinen oder nur wenigen Einschränkungen.

Kreativität und Form der Umsetzung sind keine Grenzen gesetzt. Zu jedem Inhalt kann mit jedem Medium ein OER erstellt werden. Ein einfaches Handout, Lehrpläne, Kursmaterialien, Lehrbücher, Streaming-Videos, Multimedia-Anwendungen, Podcasts, Interaktive Webelemente – alles was im Lernszenario hilfreich ist – ist willkommen. Beachtet werden sollten dabei die 5 Freiheiten für Offenheit nach Wiley.

Was sich in der Theorie einfach anhört, kann aber sowohl für Anfänger:innen als auch absolute Koryphäen immer wieder eine Herausforderung sein.

Beim HOOU-Projekt tub.torials ist die OER-Material-Erstellung u. a. von den Ersteller:innen, Thema und „Vision“ des finalen Lehr-Lernmaterials abhängig. Während die Erstellung viele Vorgehensformen haben kann, soll in diesem Beitrag ein typischer Ablauf grob skizziert werden, mit dem beispielsweise der Beitrag Was bedeutet eigentlich Open Science? entstanden ist.

1. Start – Worum geht es beziehungsweise was ist unsere Idee?

Um OER zu erstellen ist für uns zunächst eine Initialzündung nötig. Diese entsteht oftmals aus unterschiedlichen Situationen beziehungsweise Fragen heraus:

  • Gibt es einen konkreten praktischen Bedarf (beispielsweise aus dem Austausch mit Studierenden oder Kolleg:innen)?
  • Entspringt die Idee dem eigenen Arbeits- beziehungsweise Studienalltag?
  • Ist etwas für mich selbst schwer oder nur umständlich nachvollziehbar?

Oftmals führen wir individuell eine Art Ideenjournal. Geistesblitze werden hier über Mindmaps, Stichwörter oder mal mehr, mal weniger ansehnliche „Konzeptzeichnungen“ festgehalten. Haben wir dann wesentlich später eine konkretere Vorstellung, so können auch „ältere“ Einfälle wieder problemlos aufgegriffen werden und gehen nicht verloren. Selbst Klemmbausteine oder kreative Schreibansätze kommen bei der (Weiter-)Entwicklung von Ideen zum Einsatz.

Anstoß für eigene OER-Ideen gibt es über die aufgeführten Anlässe hinaus auch durch andere offene Bildungsmaterialien.

2. Material – Gibt es schon was?

Wenn wir eine etwas konkretere Idee haben, stellt sich die Frage, ob es eventuell schon etwas Vergleichbares gibt. Und wie so oft bei Rechercheaufgaben gilt: viele Wege führen nach Rom beziehungsweise zu offenen Lernmaterialien. Meine erste Anlaufstelle ist meistens die HOOU-Webseite, auf der es zahlreiche offene Bildungsmaterialien (sowie Lernangebote und -Teams) gibt. Auch das OER-Portal Niedersachsen ist eine empfehlenswerte Sammlung vieler unterschiedlicher OER-Materialien. Werde ich bei diesen Angeboten nicht fündig, so weite ich meine Suche über OERhörnchen aus. Hier lassen sich über unterschiedliche Suchoptionen u. a. deutschsprachige OER-Projekte und Bildungsangebote durchsuchen. Weitere Suchmöglichkeiten wie die Mediensuche ermöglichen zudem das Durchsuchen von Angeboten wie flickr, Wikimedia Commons oder europeana. Ebenfalls möglich ist eine komplette Websuche über Google mit Lizenzoptionen (beispielsweise „Ausschließlich nach Inhalten mit OER-kompatibler Lizenz / gemeinfreien Inhalten suchen“).

  • Screenshot der HOOU-Suche
  • Screenshot Startseite OER-Portal-Niedersachsen
  • Screenshot OERhörnchen

Wenn wir passendes Material gefunden haben, so gilt es nun die Lizenzvorgaben zu beachten.

3. Lizenzen – Was ist zu beachten?

OER-Materialien im Hochschulbereich sind oftmals mit einer CC-Lizenz (Creative Commons) versehen. Neben offiziellen Informationen zu den einzelnen Lizenzen sei auch noch diese visuelle Übersicht von Jöran Muuß-Merholz ans Herz gelegt:

CC-Lizenzen übersichtlich erklärt (Grafik von Barbara Klute und Jöran Muuß-Merholz für wb-web unter CC BY SA 3.0).

Diese funktionieren nach dem Baukastenprinzip, wobei vier Module zur Verfügung stehen:

  • Namensnennung,
  • Nicht kommerziell,
  • Keine Bearbeitung,
  • Weitergabe unter gleichen Bedingungen.

Diese Module lassen sich miteinander kombinieren, wobei wir uns bei selbst erstellten Materialien für die Veröffentlichung mit einer CC BY 4.0-Lizenz (Namensnennung) entschieden haben. Somit wollen wir eine Be- und Weiterverarbeitung unserer Materialien ohne Einschränkungen ermöglichen. Die einzige Pflicht bei dieser CC-Lizenz ist die Namensangabe. Weitere Informationen zu CC-Lizenzen bietet auch das Einführungsvideo Creative Commons-Lizenzen erklärt mit dem lehrreichen Lizenzmodulator.

Planen wir einen Remix zwischen eigenen und fremden Materialien, so ist der OER-Mixer ein hilfreiches Tool, um eventuelle Lizenzprobleme frühzeitig zu erkennen. Erstellen wir also beispielsweise einen Blogbeitrag und wollen für die Illustration nicht (nur) auf eigene Fotos zugreifen, so muss geklärt werden, ob und wie die jeweiligen Lizenzen miteinander harmonieren. Weiteres zur eigentlichen Erstellung von Lizenzhinweisen gibt es unter Punkt 5.

4. Umsetzung – Welches Tool nutzen wir?

Egal ob wir nun von Grund auf neues Bildungsmaterial erstellen oder bereits bestehendes Lernmaterial mit unseren Ideen erweitern und remixen: es stellt sich nun die Frage, mit welchen „Werkzeugen“ wir unsere Umsetzung gestalten. Anwendungen gibt es viele. Im Jahr 2020 haben wir dazu einen kleinen Community-Aufruf gemacht, an dem sich engagierte Bildungsmacher:innen aus unterschiedlichen Bereichen beteiligt haben. Teile dieser Sammlung sind bei WirLernenOnline mit eingeflossen. Eine schöne, übersichtliche Toolsammlung bietet auch das digital.learning.lab.

Für tub.torials sind oftmals kollaborative Schreib- und Ideenentwicklungsprozesse sowie interaktive Elemente relevant. Hierfür wird u. a. auf folgende Werkzeuge zurückgegriffen:

  • Etherpad: Wenn es um schnelle Erfassung von Ideen in Textform geht, so nutzen wir die TU-Instanz des Etherpads. Ohne Registrierung können hier alle Interessierten ein eigenes Pad für kollaborative Schreibprozesse aufsetzen.
  • GitLab: Die TU-Instanz von GitLab bietet zahlreiche Funktionen, die für kollaborative Projektarbeiten hilfreich sind. Neben der Möglichkeit eigene Wikis aufzusetzen, nutzen wir diese, um die Projektorganisation übersichtlicher zu gestalten. Aufgaben („issues“) werden angelegt, Teammitglieder können sich diese selbst zuweisen. Die Aufgaben durchlaufen dann in einer Art Kanboard die Bearbeitungsstufen „Open“ (die Aufgabe und die Aufgabenbeschreibung stehen fest), „Doing“ (Aufgabe wird bearbeitet, über die Kommentarfunktion können Updates und Teamdiskussionen stattfinden), „Review“ (Funktioniert das interaktive Element wie geplant, gibt es Bugs oder Verbesserungsvorschläge?) und „Closed“ (Aufgabe beziehungsweise OER-Material ist fertiggestellt und veröffentlicht). Für Aufgaben, bei denen Stillstand herrscht (u. a. „kreative Pause“, größere Herausforderungen bei der Umsetzung) steht die Bearbeitungsstufe „Auf Eis“ zur Verfügung.
  • H5P: Interaktive Elemente bauen wir mit Hilfe der offenen Anwendung H5P. Hier lassen sich z. B. interaktive Bilder, Videos oder Textaufgaben erstellen, ohne das Programmierkenntnisse notwendig sind. Für den Beitrag Was bedeutet eigentlich Open Science? haben wir – auf Basis von Erfahrungen mit Studierenden und Kolleg:innen hinsichtlich den Herausforderungen rund um das Thema Open Science – nach Erstellung der Zeichnung so den Content-Typ „Image Hot Spots“ genutzt, um einzelne Begrifflichkeiten mit weiteren Informationen auf Mausklick anzureichern. Für die Einarbeitung in H5P bietet sich das Ausprobieren der Beispiele auf der H5P-Webseite an, mit denen wir viel im Hinblick auf unsere eigenen Vorstellungen experimentiert haben. Mittlerweile gibt es auch gute Einführungen wie eine Testumgebung ohne Registrierung sowie eine H5P-Übersicht mit Schwierigkeitsgradeinschätzung des jeweiligen Aufgabentypen von Nele Hirsch, die den Einstieg zusätzlich erleichtern. Mit Lumi gibt es mittlerweile auch eine recht unkomplizierte Möglichkeit, H5P-Inhalte offline erstellen und nutzen zu können.

5. Lizenz – Erstellung über den Bildungsteiler

Nachdem wir das Material fertiggestellt haben und Texte, Titel, Beteiligte (sowie weitere Metadaten) final stehen, geht es an die Erstellung des Lizenzhinweises. Für diese nutzen wir den Bildungsteiler von Matthias Andrasch. Hier kann über eine Formulareingabe ein maschinenlesbarer Lizenzhinweis generiert werden, der ohne großen Aufwand in unsere Blogbeiträge eingebunden werden kann. Somit lassen sich die entsprechenden Materialien bei der Recherche über die gängigen Suchtools gezielt finden.

Formular, über das sich am Ende durch Eingabe von Informationen wie Namen der Ersteller:innen, Werktitel und gewählte Lizenz eine maschinenlesbare Lizenz auswerfen lässt.
Maschinenlesbare CC-Lizenzen lassen sich einfach mit dem Bildungsteiler von Matthias Andrasch erstellen (Screenshot: nicht unter freier Lizenz)

Für Bilder aus der Wikipedia oder Wikimedia Commons kann für die Erstellung eines Lizenzhinweises auch auf den Lizenzhinweisgenerator zurückgegriffen werden.

6. Multiplikation – Sharing is caring

Unsere OER-Materialien bieten wir über das tub.torials-Blog an. Hier haben wir aktuell gute Möglichkeiten, Beiträge mit interaktiven Elementen auf unsere Bedürfnisse hin aufzubereiten. Über die HOOU-Webseite weisen wir auf das Projekt hin. Zusätzlich haben wir ein eigenes Gitlab-Repositorium, wo wir beispielsweise unsere Blogbeiträge sowie die dazugehörigen Medien (Illustratioen, Videomaterial, H5P-Elemente, etc.) in offenen (Markdown) sowie gängigen Formaten (Docx, PDF) zur freien Verfügung stellen.

Auf der tub.-Webseite werden Beiträge des tub.torials-Blogs über einen Feed mit eingespielt und auch Twitter wird genutzt, um auf Beiträge und Materialien hinzuweisen.

7. Feedback – Austausch mit Anderen

Wenn es sich bei unserem Material um einen Remix bereits vorhandener Materialien, öffentlich geteilter Ideen oder andere Formen der Insipration von anderen Bildungsmacher:innen handelt, so ist es für uns wichtig, den Ideengeber:innen Bescheid zu geben. Für uns gehört dies einerseits zum guten Ton, andererseits entsteht hier oftmals auch eine gute Basis für weiteren Austausch oder gemeinsame Projekt- und Materialideen.

Offene Fragen?

Habt ihr noch Fragen zu unseren Erstellprozessen oder dem tub.torials-Blog? Teilt uns diese gerne über die Kommentarfunktion, Twitter (Florian Hagen, Thomas Hapke) oder per Mail mit. Auch über eure Erfahrungen und Einblicke in die eigene Erstellung von OER freuen wir uns 🙂

CC BY 4.0
Weiternutzung als OER ausdrücklich erlaubt: Dieses Werk und dessen Inhalte sind – sofern nicht anders angegeben – lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: Wie machen wir OER? Einblicke bei tub.torials von Florian Hagen, Lizenz: CC BY 4.0. Der Beitrag und dazugehörige Materialien stehen auch im Markdownformat und als PDF zum Download zur Verfügung. Die Originalveröffentlichung ist bei Insights verfügbar. Hinweise zur Bearbeitung: Der Beitrag wurde um einen einführenden Hinweistext ergänzt. Die erste Zwischenüberschrift wurde entfernt. Es wurden sprachliche Anpassungen vorgenommen (u. a. Gender-Form, Ausdruck und Füllwörter) sowie nicht mehr funktionierende Links aktualisiert. Die Kapitel 1 (zusätzlicher Aufzählungspunkt), 2 (OER-Portal Niedersachsen hinzugefügt), 3 (Einführungsvideo ergänzt), 4 (Namensanpassung „Hedgedoc“ und Anwendung „Lumi“ hinzugefügt), 5 (Lizenzhinweisgenerator hinzugefügt) und 6 (Multiplikationsmöglichkeiten erweitert) wurden inhaltlich erweitert und angepasst. Mit Ausnahme des Beitragsbildes und der Illustration „CC-Lizenzen übersichtlich erklärt“ wurde das Bildmaterial neu erstellt. Der Text ist im Markdownformat und als PDF verfügbar.
1 2