Bilder sichtbar gemacht für Review

Website/content/posts/2025-04-10-So-arbeiten-wir/index.md

@@ -0,0 +1,172 @@
+---
+'@context': https://schema.org/
+creativeWorkStatus: Published
+type: LearningResource
+name: >-
+  So arbeiten wir in der oer.community: Offen, transparent, kollaborativ
+description: >-
+  Wie organisiert man ein OER-Projekt offen und gemeinschaftlich? Dieser Beitrag gibt einen praxisnahen Einblick in die Arbeitskultur und die digitalen Workflows im Projekt FOERBICO. Offene Repositorien, Git-gestützte Zusammenarbeit, transparente Aufgabenverwaltung und kollaborative Texterstellung prägen den Projektalltag und machen nachvollziehbar, wie Open Educational Practices (OEP) gelebt werden.
+license: https://creativecommons.org/licenses/by/4.0/deed.de
+id: https://oer.community/so-arbeiten-wir
+creator:
+  - givenName: Jörg
+    familyName: Lohrer
+    id: https://orcid.org/0000-0002-9282-0406
+    type: Person
+    affiliation:
+      name: Comenius-Institut
+      id: https://ror.org/025e8aw85
+      type: Organization
+  - givenName: Gina
+    familyName: Buchwald-Chassée
+    type: Person
+    affiliation:
+      name: Comenius-Institut
+      id: https://ror.org/025e8aw85
+      type: Organization
+keywords:
+  - OER
+  - Open Educational Practices
+  - Git
+  - Kollaboration
+  - FOERBICO
+  - Community
+  - Versionsverwaltung
+inLanguage:
+  - de
+about:
+  - https://w3id.org/kim/hochschulfaechersystematik/n052
+  - https://w3id.org/kim/hochschulfaechersystematik/n079
+  - https://w3id.org/kim/hochschulfaechersystematik/n544
+image: >-
+  https://oer.community/so-arbeiten-wir/foerbildfunktion.jpg
+learningResourceType:
+  - https://w3id.org/kim/hcrt/text
+  - https://w3id.org/kim/hcrt/web_page
+educationalLevel:
+  - https://w3id.org/kim/educationalLevel/level_A
+datePublished: '2025-05-06'
+author:
+  - Jörg Lohrer
+  - Gina Buchwald-Chassée
+title: 'So arbeiten wir in der oer.community: Offen, transparent, kollaborativ'
+cover:
+  relative: true
+  image: foerbildfunktion.jpg
+url: so-arbeiten-wir
+tags:
+  - OER
+  - OEP
+  - Kollaboration
+  - Git
+  - Workflow
+  - Community
+---
+
+
+# So arbeiten wir in der oer.community
+
+## Vorweg: Offene Projektkultur im Kontext von FOERBICO
+
+Das Projekt **FOERBICO** (Förderung offener Bildungspraktiken in religionsbezogenen Communities durch die Entwicklung eines koordinierten OER-Ökosystems) wird vom [Comenius-Institut ](https://comenius.de/2024/03/28/foerderung-offener-bildungspraktiken-in-religionsbezogenen-communities-durch-die-entwicklung-eines-koordinierten-oer-oekosystems-foerbico/)in Kooperation mit der Goethe-Universität Frankfurt (GU) und der FAU Erlangen-Nürnberg durchgeführt. Ziel ist es, bislang isolierte Aktivitäten in OER-Communities zu vernetzen und offene Bildungspraktiken (Open Educational Practices, *OEP*) zu stärken. Diese offene Ausrichtung spiegelt sich nicht nur in den Projektzielen wider, sondern auch in der Art und Weise, **wie wir im Projekt zusammenarbeiten**. Alle Arbeitsprozesse – von der technischen Entwicklung bis zur inhaltlichen Redaktion – erfolgen transparent, kollaborativ und unter Nutzung offener und nachnutzbarer digitaler Werkzeuge unter freien Nutzungslizenzen. Im Folgenden dokumentieren wir unsere Arbeitsweise als Team, um Beteiligten und Fördernden einen Einblick in unsere Methoden zu geben. Gleichzeitig soll dieser Beitrag neuen Mitarbeitenden als Anleitung dienen.
+
+Wir nutzen konsequent eine offene, git-basierte Infrastruktur zur Organisation des Projekts. Das bedeutet, dass *alle* Projektmaterialien, Aufgaben und Ergebnisse in **Versionkontrollrepositories (Git)** verwaltet werden und somit für das Team (und wo immer dies datenschutzkonform möglich ist, weitestgehend auch für die Öffentlichkeit) einsehbar sind. Dadurch gewährleisten wir Transparenz über den Projektfortschritt und ermöglichen Zusammenarbeit über Institutionsgrenzen hinweg. Im Sinne von OEP fördern wir eine Kultur des Teilens und der gemeinsamen Verantwortung: Inhalte werden als Open Educational Resources (OER) unter freier Lizenz erstellt, und auch die Prozesse zu ihrer Entstehung sind offen nachvollziehbar. Im Folgenden beschreiben wir die zentralen technischen Abläufe (Git-Workflows, Branching, Merge-Strategien, Continuous Integration) und die redaktionelle Zusammenarbeit (Texterstellung, Review, Aufgabenverteilung) im Projekt. Abschließend heben wir hervor, wie diese Praktiken zur offenen Bildungsarbeit beitragen, und geben praktische Hinweise für den Einstieg neuer Teammitglieder und zu Kooperationsmöglichkeiten beispielsweise in der [OER-Strategie](https://www.oer-strategie.de/).
+
+## Versionsverwaltung und Repository-Struktur
+
+Im FOERBICO-Projekt setzen wir auf Git als zentrales Werkzeug für Versionsverwaltung und Kollaboration. Unsere Projektmaterialien liegen in einem Git-Repository auf der Plattform [**git.rpi-virtuell**](https://git.rpi-virtuell.de/) ([Forgejo](https://forgejo.org/)-basiert). [Dieses Hauptrepository](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO) enthält den gesamten Quelltext der Projekt-Website sowie begleitende Dokumentation und Bildungsinhalte. Der Repository-Titel sowie die Beschreibung machen unseren Projektauftrag direkt ersichtlich. Mit derzeit 16 Branches und über 600 Commits (Stand: April 2025) zeigt sich zunehmend eine rege Entwicklungs- und Redaktionstätigkeit. Die Nutzung von Git ermöglicht uns, **Änderungen an Dateien nachzuverfolgen**, frühere Versionen wiederherzustellen und parallel an verschiedenen Inhalten zu arbeiten, ohne Datenverlust oder Konflikte.
+
+**Struktur des Repositories:** Wir haben im Repository eine klare Ordnerstruktur etabliert, welche technische Komponenten und redaktionelle Inhalte trennt. Beispielsweise liegen Quellcode und Design der Website im Ordner `Website/` und `design/`, während Anleitungen, Präsentationen sowie Lehr- und Lernmaterialien im in Markdown-Dateien in sich entwickelnden Verzeichnisstrukturen abgelegt sind. Zusätzliche Verzeichnisse wie `assets/` dienen der Ablage von Bildern und Medien. Außerdem existiert ein Verzeichnis `archiv/`, in dem wir projektbezogene Berichte und archivierte Dokumente versioniert ablegen (z. B. Projektzwischenberichte als Markdown). Zentrale Übersichts- und Planungsdokumente sind als Markdown-Dateien vorhanden, darunter `README.md` (Einstiegsinformationen), `Ziele.md` (Projektziele), `Meilensteine.md` (Übersicht der Arbeitspakete). So ist es beispielsweise möglich, dass wir [ein sich aktualisierendes Gantt-Chart der Projektplanung hier interaktiv](https://projekt.oer.community/gantt/) direkt mit den Meilensteinen und zugeordneten Aufgaben erschließbar machen können. Aus der Datei `FOERBICO-Workflow.drawio` lässt sich kooperativ und versionierbar [hier ein Diagramm unserer internen Arbeitsabläufe](https://app.diagrams.net/?src=about#Uhttps%3A%2F%2Fgit.rpi-virtuell.de%2FComenius-Institut%2FFOERBICO%2Fraw%2Fbranch%2Fmain%2FFOERBICO-Workflow.drawio#%7B%22pageId%22%3A%22Ht1M8jgEwFfnCIfOTk4-%22%7D) transparent entwickeln. Durch diese offene Dokumentation direkt im Repository sind alle Teammitglieder stets auf demselben Stand bezüglich Zielsetzungen, Zeitplanung und Verantwortlichkeiten.
+
+**Offene Lizenzierung:** Sämtliche Inhalte im Repository unterliegen offenen Lizenzen. Wir verwenden vornehmlich die [*Creative Commons BY 4.0*](https://creativecommons.org/licenses/by/4.0/deed.de)-Lizenz, wie in unseren [Mitwirkungsrichtlinien](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/src/branch/main/contributing.md) festgehalten. Das bedeutet, dass alle neu erstellten oder bearbeiteten Materialien von uns offen nachnutzbar sind, sofern Urheberschaft genannt wird. Diese Lizenz ist im Repository durch die Datei [`LICENSE`](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/src/branch/main/LICENSE) und entsprechende Hinweise in den Beitragsrichtlinien verankert. Damit stellen wir sicher, dass nicht nur unsere Prozesse offen sind, sondern auch die entstehenden Bildungsressourcen frei verwendet werden dürfen – ein Kernprinzip von Open Educational Resources.
+
+Zusätzlich zum Hauptrepository existieren weitere spezialisierte Repositories innerhalb der selbstgehosteten Git-Plattform sowie auf gitlab und github, etwa für die Verwaltung von Metadaten. Ein Beispiel ist das [**OERSI-Datensatz**-Repository](https://gitlab.com/comenius-institut/foerbico/oersi-datensatz), über das wir Metadaten zu unseren OER-Inhalten für den übergreifenden OER-Search-Index (OERSI) bereitstellen (dies wurde im Oktober 2024 angelegt und enthält strukturierte Metadaten). Solche Teil-Repositories ermöglichen es, technische Komponenten oder Datenbestände auszulagern und separat zu versionieren, während wir über das Hauptprojekt-Repository die Gesamtkoordination behalten. Alle Repositories unter dem FOERBICO-Dach sind im Comenius-Institut Gitlab/Forgejo aufgeführt und mit dem Projekt verknüpft, was eine konsistente Nutzung von Issues und Meilensteinen (siehe unten) über Projektgrenzen hinweg ermöglicht.
+
+## Aufgabenverwaltung mit Issues, Labels und Meilensteinen
+
+Zur **Organisation von Aufgaben und Projektmanagement** nutzen wir intensiv das integrierte Issue-Tracking-System der Git-Plattform. Jedes Arbeitspaket, jede Idee oder jedes Problem wird als **Issue** erfasst. Dies fördert transparente Diskussionen: alle Kommentare, Entscheidungen und Zuständigkeiten zu einer Aufgabe sind an einem Ort dokumentiert. Aktuell werden über 100 [offene Issues in unserem Hauptrepository](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/issues) parallel verwaltet (Stand April 2025: z. B. 125 offene und 115 geschlossene Issues), was den aktiven Fortschritt und kontinuierlichen Abschluss von Aufgaben widerspiegelt.
+
+**Label-System:** Um die Vielzahl an Issues übersichtlich zu halten, etablieren wir ein **System von Labels (Schlagworten)** und ordnen Zuständigkeiten sowie die Meilensteine aus den Arbeitspaketen unserer Projektplanung zu. Jedes Issue wird mit mindestens einem Label versehen, das seinen Typ oder Themenbereich kennzeichnet. Beispiele für Labelkategorien in unserem Projekt sind: 
+
+- **Inhaltliche Art:** *Blog* (für Blogartikel und redaktionelle Beiträge), *Events* (für Veranstaltungsorganisation), *Offene Frage* (Diskussions- oder Klärungsbedarf), *Verbesserung* (Vorschläge zur Weiterentwicklung), *Fehler/Bug* (technische Probleme). 
+- **Zuständigkeit/Team:** *technik* (für technische Aufgaben des Informatik-Teams), oder Labels mit Partnerkürzeln wie *FAU* bzw. *GU*, um Aufgaben der jeweiligen Hochschulpartner zu markieren. So ist sofort erkennbar, wer primär involviert ist. 
+- **Projektmitarbeitende einbinden:** Wir nutzen auch Labels, um die Einbindung neuer oder externer Mitwirkender zu erleichtern, etwa *gutes erstes Issue* (eine Einstiegsaufgabe für neue Mitglieder) und *Hilfe gesucht* (hier werden Beiträge aus der Community explizit erwünscht). Diese Markierungen im Sinne von OEP signalisieren unsere Offenheit über die eigene Projektgrenze hinweg zu beteiligen: Interessierte Personen können sich niedrigschwellig einbringen, indem sie solche Issues übernehmen.
+
+Durch die Kombination von Labels lassen sich Issues filtern (z. B. alle offenen technischen Bugs) und gezielt zuordnen. Das gesamte Team hat damit stets den Überblick, welche Aufgaben anstehen und welcher Natur sie sind.
+
+**Meilensteine und Arbeitspakete:** Zur langfristigen Planung sind unseren Issues **Meilensteine** zugeordnet. Wir orientieren uns dabei an den formal definierten **Arbeitspaketen (AP)** des Projektantrags. Jedes Arbeitspaket (z. B. [*AP 11-1 Basiserhebung (FAU)*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/milestone/10)) wird als Meilenstein im System abgebildet. So werden zusammengehörige Aufgaben gebündelt und ihrem übergeordneten Ziel zugewiesen. Beispiel: Das Arbeitspaket [*AP 4-3 + 4-4: Metadaten-Generator für OEP/OER*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/milestone/90) umfasst mehrere technische Issues zur Entwicklung eines Tools – all diese Issues tragen den entsprechenden Meilenstein, wodurch Fortschritt und verbleibende To-Dos in diesem Bereich nachvollziehbar sind. Einige Meilensteine sind an bestimmte Projektphasen oder Zyklen gekoppelt (etwa Evaluationszyklen), was wir ebenfalls im Namen kenntlich machen. Sobald alle Issues eines Meilensteins erledigt sind, gilt das entsprechende Arbeitspaket als abgeschlossen und der Meilenstein wird geschlossen (beispielsweise wurde *[AP 9-3 Kollaborationsumgebung für das Projekt (CI)*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/milestone/4) bereits erfolgreich implementiert.
+
+Die Verwendung von Meilensteinen stellt sicher, dass das **operative Issue-Tracking mit der strategischen Projektplanung** verzahnt ist. Projektleitung und Fördermittelgeber können so den Fortschritt je Arbeitspaket direkt im System mitverfolgen. Zudem können wir Fälligkeiten (Due-Dates) an Issues vergeben, um fristgebundene Entwicklungsziele zu steuern – etwa ist für gewisse Forschungsaufgaben eine Erledigung bis Projektende (z. B. August 2026) hinterlegt.
+
+**Kanban-Projekttafeln:** Neben der linearen Liste aller Issues nutzen wir **Projekttafeln** (Boards), um Aufgaben innerhalb bestimmter Kontexte agil zu organisieren. Wir haben mehrere **Project Boards** eingerichtet, die thematisch oder teambezogen gruppiert sind.
+
+- [*Blogposts Redaktion*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/projects/25): Board für alle Aufgaben rund um Blogartikel und redaktionelle Beiträge. Hier bewegen sich Issues typischerweise vom Stadium "Idee" über "In Arbeit" bis "Veröffentlicht".
+- [*Projekt-Technik*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/projects/2): Board für technische Entwicklungsaufgaben (Software, Infrastruktur). Das Informatik-Team priorisiert hier Bugs und Features.
+- [*Webseite oer.community*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/projects/38): Board spezifisch für Aufgaben zur Projekt-Website (Inhalte einpflegen, technische Anpassungen am Webauftritt).
+- [*Austausch FOERBICO Team*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/projects/33): Board für allgemeine Team-Aufgaben und den regelmäßigen internen Austausch. Hier werden z. B. Vorbereitungspunkte für Teammeetings oder Workshops gesammelt.
+- [*Empirische Begleitforschung*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/projects/41): Board für Forschungsaufgaben (Interviews, Erhebungen, Auswertungen) der wissenschaftlichen Verbundpartner.
+- [*(biweekly)*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/projects/26): Ein Board namens "biweekly" nutzen wir für die 14-tägigen Sprints bzw. Meetings, in denen wir mit allen Projektbeteiligten Absprachen treffen und unsere Aufgaben planen und nachverfolgen.
+
+Jede dieser Tafeln bietet Spalten wie "To Do", "In Bearbeitung" und "Erledigt". Die Teammitglieder verschieben ihre Issues entsprechend des Bearbeitungsstandes. Dieses visuelle Management hilft, **Arbeitsstände schnell zu überblicken** und Engpässe zu erkennen (z. B. wenn zu viele Aufgaben gleichzeitig in Bearbeitung sind). Beispielsweise sieht man auf einen Blick alle aktuell in Arbeit befindlichen Blogartikel im Board *Blogposts Redaktion*. Das fördert auch die Selbstorganisation: Teammitglieder können eigenständig neue Aufgaben aus dem Backlog ziehen, wenn Kapazität frei wird. Insgesamt ergänzen die Kanban-Tafeln das Issue-System um eine **dynamische, sprintorientierte Perspektive** und tragen zu einer agilen Projektsteuerung bei.
+
+## Git-Workflow: Branching, Pull Requests und Continuous Integration
+
+Für die praktische Zusammenarbeit am Repository folgen wir einem klar definierten **Git-Workflow**, der sowohl paralleles Arbeiten ermöglicht als auch Qualität durch Review sicherstellt.
+
+**Branching-Strategie:** Wir arbeiten primär auf dem zentralen **Main-Branch**, der den jeweils aktuellen freigegebenen Projektstand repräsentiert. Neue Funktionen, Inhalte oder größere Änderungen entwickeln wir in eigenen **Feature-Branches**. Diese Branches werden aussagekräftig benannt, oft nach dem Inhalt oder der Issue-Nummer. Beispielsweise wurden Blogartikel in Branches wie `feature/blogartikel-nostr-dezentrale-oer-oep` vorbereitet. Durch diese Aufteilung kann ein Teammitglied an einem neuen Artikel oder einem Code-Feature arbeiten, ohne den Main-Branch (und damit die live sichtbare Website) zu beeinträchtigen. Mehrere Branches (aktuell ~16 parallel vorhandene) bedeuten, dass verschiedene Teammitglieder und Teilprojekte gleichzeitig voranschreiten.
+
+**Zusammenführung via Pull Requests:** Ist eine Arbeit auf einem Branch abgeschlossen, stellen wir einen **Merge Request (Pull Request)**. Dieser Mechanismus ermöglicht es, die geplanten Änderungen vom Branch in den Main-Branch zu überführen, **nachdem eine Qualitätskontrolle stattgefunden hat**. Im Pull Request sehen alle Beteiligten den **diff** (die konkreten Änderungen) und eine **Diskussionsmöglichkeit**, um Feedback zu geben. Typischerweise muss mindestens eine andere Person den Request überprüfen und freigeben. FOERBICO hat hier einen hohen Qualitätsanspruch: Bei inhaltlichen Beiträgen (z. B. Blogposts) schauen oft sowohl jemand aus dem Redaktionsteam als auch jemand aus dem Technikteam drüber. Unser Repository vermerkt bei Merge-Commits explizit, wer den Beitrag reviewt hat – so finden sich in den Commit-Metadaten *Reviewed-by*-Einträge mit Name und E-Mail der Reviewer. Erst wenn die Reviews positiv sind, wird der Pull Request gemergt (entweder automatisch durch das System oder manuell vom Repository-Owner). Dieses **Vier-Augen-Prinzip** stellt sicher, dass Fehler, Unklarheiten oder Unstimmigkeiten (sowohl inhaltlich als auch technisch) vor dem Livegang behoben werden. 
+
+Beim Merge führen wir in der Regel einen echten **Merge-Commit** durch, d.h. die History des Feature-Branches (ein oder mehrere Commits) wird in den Main-Branch integriert und mit einer Merge-Nachricht abgeschlossen. Dadurch bleibt die Entwicklungshistorie nachvollziehbar – man kann später sehen, welche einzelnen Commits zu einer Funktion oder einem Artikel gehörten und welche Diskussion dem Merge vorausging (der PR bleibt als Referenz erhalten, inkl. Issue-Nummer #XYZ im Commit-Kommentar). Für sehr kleine Änderungen nutzen wir fallweise auch "Squash and Merge", um die History kompakt zu halten, aber der Regelfall ist das normale Mergen mit allen Commits.
+
+**Continuous Integration (CI) und Deployment:** Ein wesentlicher Bestandteil unseres Workflows ist die automatisierte **Continuous-Integration-Pipeline**. Bei jedem Push in das Repository (insbesondere bei Merge auf den Main-Branch) wird unser CI-System (**Woodpecker CI**) aktiviert. Eine definierte Pipeline (YAML-Konfiguration in `.woodpecker/`) führt verschiedene Schritte aus, um die Änderungen zu verarbeiten. Im FOERBICO-Projekt umfasst dies insbesondere das **Bauen und Bereitstellen der Website**. Konkret stößt der Pipeline-Schritt *build_and_copy_website* den Prozess an, aus den Markdown-Inhalten und Quellcodes die aktualisierte Webseite zu generieren und auf den Webserver zu kopieren. So werden neu geschriebene Blogartikel oder geänderte Seiten **automatisch online gestellt**, sobald sie in `main` gemergt sind. Die erfolgreiche Ausführung der Pipeline wird im Repository angezeigt („All checks were successful“); im Fehlerfall würde das Team sofort eine Benachrichtigung erhalten und könnte eingreifen. Diese CI-Integration fördert schnelle Rückmeldungen: Teammitglieder sehen umgehend, ob ihre Änderungen buildbar sind und wie sie live aussehen. Außerdem minimiert sie manuellen Aufwand – das Deployment erfolgt künftig dann auf Knopfdruck, was menschliche Fehler z.B. beim Hochladen vermeidet.
+
+Neben dem Webseiten-Build können in der Pipeline auch weitere Aktionen definiert sein, etwa das Validieren von Metadaten oder Tests für Skripte. Beispielsweise haben wir Aufgaben, OER-Metadaten im OERSI-Format bereitzustellen; hier könnte CI prüfen, ob neue Beiträge Metadaten enthalten und ggf. automatisiert YAML-Dateien aktualisieren. Hier wollen wir eine Routine entwickeln, die aus den Blogposts Maschinendaten erzeugt und z.B. ans OERSI-GitLab sendet – solche Integrationen lassen sich elegant über CI-Skripte realisieren. Auch die Anbindung an offene Forschungsdaten-Repositorien wird angestrebt: So wurde in unserem Workflow-Diagramm bereits die Einbindung von **OSF (Open Science Framework) und Zenodo** vorgesehen, um Projektergebnisse oder Datensätze parallel auch dort publizieren zu können. Die technische Infrastruktur von FOERBICO ist damit konsequent auf Offenheit und Automatisierung ausgerichtet.
+
+Zusammenfassend garantiert der Git-Workflow mit Feature-Branches, Reviews und CI, dass **hohe Qualität und Aktualität** unserer Projektoutputs sichergestellt sind, ohne die Kollaborationsfähigkeit einzuschränken. Jeder im Team kann autonom arbeiten und Beiträge leisten, während Git und CI für saubere Integration sorgen. Transparenz ist auch hier ein Plus: Die CI-Logs sind für das Team einsehbar, so dass jeder z.B. den Verlauf eines Website-Deployments nachvollziehen kann.
+
+## Redaktionelle Zusammenarbeit und Review-Prozesse
+
+Die Erstellung von Texten und Bildungsinhalten im Projekt folgt ebenfalls einem strukturierten, offenen Prozess, der sich eng an Software-Entwicklungsworkflows anlehnt. **Redaktionelle Beiträge (z.B. Blogartikel, Handreichungen, Lehrmodule)** entstehen in Kollaboration über Git:
+
+![](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/raw/branch/add-blogpost-so-arbeiten-wir/Website/content/posts/2025-04-10-So-arbeiten-wir/Redaktionsprozess.png)
+
+- **Ideenfindung und Planung:** Neue Inhalte starten häufig als *Issue*. Hat jemand z.B. die Idee für einen Blogbeitrag über ein Projektthema, wird ein Issue mit einem sprechenden Titel erstellt (z.B. der Issue [*"Blogbeitrag Workflow/Selbstmanagement darstellen"*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/issues/329), der zu diesem Artikel geführt hat. In der Beschreibung können bereits Stichpunkte oder ein grober Umriss festgehalten werden. Das Issue wird typischerweise dem Board *Blogposts Redaktion* zugeordnet und mit Label *Blog* markiert. So ist von Anfang an klar, dass es sich um eine redaktionelle Aufgabe handelt. Oft werden in der frühen Phase im Issue schon **Rollen verteilt** – etwa wer den ersten Entwurf schreibt und wer später gegenliest – und **Material gesammelt** (Quellen, Links, Abbildungen).
+
+- **Texterstellung im Branch:** Die eigentliche Ausarbeitung erfolgt dann in einem eigenen Git-Branch, wie im vorherigen Abschnitt beschrieben. Der Autor oder die Autorin legt eine neue Markdown-Datei im `Website/`-Verzeichnis an, oft mit Datum und Thema im Dateinamen (etwa `2025-04-10-So-arbeiten-wir/index.md`). Beim Schreiben achten wir auf einheitliche Formatierung. Hilfreich ist unsere bereitgestellte **Markdown-Vorlage** (`Markdownvorlage.md` im Repo) mit Beispielen für Überschriften, Listen, Zitate etc., damit alle Beiträge einen konsistenten Aufbau haben. Während der Schreibphase können auch weitere Commits von anderen Teammitgliedern auf den Branch kommen – beispielsweise um bereits Rechtschreibfehler zu korrigieren oder Inhalte zu ergänzen. Git erleichtert hier die **gleichzeitige Mitarbeit**: Konflikte sind selten, da Textabschnitte separat bearbeitet werden können.
+
+- **Review und Qualitätssicherung:** Ist der Entwurf fertig, wird ein Pull Request eröffnet, um den Artikel nach *main* zu mergen. Jetzt startet der **redaktionelle Review-Prozess**. Mindestens eine zweite Person liest den Artikel kritisch gegen. Dabei achten wir sowohl auf fachliche Richtigkeit und Didaktik als auch auf sprachliche und formale Qualität sowie auf standardisierte Metadaten. Änderungen aus dem Review werden wiederum als Commits auf dem Feature-Branch eingepflegt – der PR aktualisiert sich automatisch. Ein Beispiel: In einem PR zu einem Blogartikel wurden in zwei Commits kleine Verbesserungen vorgenommen (*"fix typos and header format"*, *"Artikel an bisherige Logik anpassen, Emoji als Unicode"*) bevor gemergt wurde [(#284)](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/pulls/284). So sieht man lückenlos, welche Anpassungen der Review ergeben hat. Gegebenenfalls wird auch die Projektkoordination oder weitere Fachexpertise hinzugezogen, gerade wenn es um sensiblere Inhalte oder externe Publikationen geht. Erst wenn Konsens über die Qualität besteht, erfolgt der Merge (inkl. „Reviewed-by“-Vermerken, siehe oben).
+
+- **Publikation:** Durch das Merge in den Main-Branch und die CI-Pipeline ist der neue Inhalt kurz darauf auf der Website veröffentlicht. Bei Blogartikeln erfolgt die Veröffentlichung praktisch sofort automatisiert. Bei anderen Materialien, etwa einem ausführlichen Leitfaden als Markdown-Dokument, würde analog verfahren: nach dem Merge wäre das Dokument z.B. im Repository (oder der Website zum Download) verfügbar. Wichtig ist: **Die gesamte Entstehungsgeschichte des Inhalts ist offen nachvollziehbar**. Von der ersten Idee im Issue über die verschiedenen Entwurfsstände bis zur finalen Veröffentlichung bleibt alles dokumentiert. Dies ermöglicht nicht nur Transparenz nach außen, sondern erleichtert auch intern die Nachvollziehbarkeit von Entscheidungen (z.B. warum ein Absatz gestrichen oder geändert wurde).
+
+Ergänzend zu Git nutzen wir für die redaktionelle Zusammenarbeit auch Kommunikationstools wie z.B. den dezentralen Messenger Matrix/Element, die Nextcloud oder E-Mail, aber alle finalen inhaltlichen Änderungen fließen wieder ins Repository zurück. Auf diese Weise geht kein Wissensstand verloren – es gibt *eine zentrale Quelle der Wahrheit* für jeden Text: die Version im Git. So bleibt jede Mitarbeit inder Beitrags-Historie und damit auch das beteiligte Wissen im Repository erhalten. 
+
+**Aufgabenverteilung im Redaktionsteam:** Durch das offene Issue-Board können sich Teammitglieder aktiv Aufgaben zuweisen. Oft wird das im Issue selbst vermerkt („@username übernimmt den ersten Entwurf“). Das System erlaubt auch formale Zuweisung eines Issues an eine Person (*Zuständige*), was wir nutzen, um Verantwortlichkeiten zu dokumentieren. In der Praxis herrscht aber eine flexible Haltung: jede/r darf kommentieren und beitragen, auch wenn er/sie nicht offiziell zugewiesen ist. Die Labels nach Partner (z.B. FAU, GU) markieren primär die Federführung, schließen Kollaboration aber nicht aus. Durch wöchentliche/ zweiwöchentliche Team-Calls (deren Ergebnisse im Board *biweekly* nachgehalten werden) erfolgt Abstimmung darüber, wer welche Prioritäten übernimmt. Somit ist die *Aufgabenverteilung* sowohl klar (jede Aufgabe hat einen verantwortlichen Bearbeiter) als auch offen für Mitarbeit (jede/r darf Vorschläge einbringen).
+
+**Externe Zusammenarbeit:** Im Sinne von OEP beziehen wir nicht nur interne Projektmitglieder ein, sondern öffnen die redaktionelle Arbeit auch für externe Mitwirkende, soweit möglich. Unser Repository ist öffentlich lesbar, und wir haben niederschwellige Mitwirkungsrichtlinien formuliert, um interessierte Personen anzusprechen. Darin laden wir ausdrücklich dazu ein, neue Inhalte beizutragen, bestehende Inhalte zu verbessern oder zu übersetzen. Externe können über das Issue-Tracker Feedback geben oder eigene Vorschläge als Issues einstellen. Kommt es zu externen Pull Requests, behandeln wir diese analog zu internen: via Review und Merge. Da alle Inhalte unter offener Lizenz stehen, ist es für Außenstehende attraktiv und erlaubt, unsere Materialien weiterzuverwenden und Verbesserungen zurückzumelden. Dieser fließende Übergang zwischen interner Redaktion und Community-Beiträgen bereichert die Qualität unserer OER und verbreitert die Autorenschaft – ganz im Sinne kollaborativer Content-Erstellung.
+
+## Offene Praktiken (OEP) und Transparenz im Arbeitsprozess
+
+Unsere Arbeitsweise verkörpert **Open Educational Practices** auf mehreren Ebenen. OEP bedeutet, dass nicht nur die Endprodukte offen sind, sondern der gesamte Prozess auf Offenheit, Partizipation und kontinuierliches Lernen ausgelegt ist. Im Projekt FOERBICO setzen wir dies folgendermaßen um:
+
+![](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/raw/branch/add-blogpost-so-arbeiten-wir/Website/content/posts/2025-04-10-So-arbeiten-wir/Grafik-1.jpg)
+
+- **Transparenz der Prozesse:** Alle Projektaktivitäten werden offen sichtbar gemacht. Das Issue-Tracking ist – abgesehen von eventuell sensiblen Einträgen – öffentlich einsehbar. Externe können nachvollziehen, woran das Team arbeitet, welche Probleme diskutiert werden und wie Lösungen gefunden werden. Diese *Working-out-loud*-Philosophie fördert Vertrauen und lässt Stakeholder am Fortschritt teilhaben, ohne dass wir für Berichte extra geschlossene Kreisläufe brauchen. Selbst unsere Zeitplanung (Meilensteine) und Dokumentation sind als Dateien öffentlich versioniert, nicht in internen Ordnern versteckt. Das erhöht auch die *Verbindlichkeit*: Was einmal im Issue festgehalten ist, wird nicht übersehen.
+
+- **Offener Zugang zu Wissen:** Durch die zentrale Nutzung von Git und Markdown sind alle Wissensartefakte (von Code bis Dokumentation) frei zugänglich. Neue Teammitglieder oder interessierte Kollegen aus den Partnerinstitutionen können sich eigenständig ins Projekt einlesen, indem sie das Repository und die Wiki/Dateien durchstöbern. Wir haben z.B. eine offene Nextcloud-Kalenderintegration, in der alle Termine und Meilensteine eingetragen sind, die sogar über die Webseite eingebettet öffentlich sind. Das bedeutet, auch Projektevents oder wichtige Deadlines sind transparent. Die Hemmschwelle Informationen zu erbitten sinkt, weil vieles proaktiv geteilt wird.
+
+- **Kollaborative Arbeitskultur:** Die gewählten Tools und Workflows fördern *Kollaboration statt hierarchischer Steuerung*. Jeder kann Vorschläge machen (Issue erstellen), jeder Beitrag wird wertgeschätzt und geprüft (Pull-Request-Reviews). Unsere Labels *“Hilfe gesucht”* und *“gutes erstes Issue”* signalisieren, dass wir ausdrücklich Mitstreiter willkommen heißen. Auch interne Hierarchien (verschiedene Qualifikationsniveaus und Rechte im Team) entwickeln durch den einheitlichen Workflow zu einer heterarchischen und gleichberechtigten Arbeitsweise – ein Beitrag einer studentischen Hilfskraft durchläuft den gleichen Reviewprozess wie der eines Lehrstuhlinhabers, und beide erhalten konstruktives Feedback. Das gemeinsame Repository schafft ein Gefühl von *Co-Ownership* an den Materialien: Es sind nicht „meine“ oder „deine“ Dokumente, sondern unsere gemeinsamen OER.
+
+- **Qualität durch Offenheit:** Indem wir unsere Inhalte offen erarbeiten, unterziehen wir sie automatisch einem breiteren Feedback und Qualitätscheck. Fehler können von anderen entdeckt werden (Peer Review). Die Offenheit motiviert zur Sorgfalt – man schreibt anders, wenn man weiß, dass die ganze Community potentiell mitliest. Zudem ermöglichen die offenen Arbeitsprozesse **kontinuierliches Lernen im Team**: z.B. können weniger erfahrene Mitglieder durch das Review der Erfahrenen viel über guten Stil, Didaktik oder sauberen Code lernen, weil alle Änderungen sichtbar sind. Dieses *Learning by Doing in Public* steigert langfristig die Kompetenzen aller Beteiligten.
+
+- **Nachhaltigkeit und Nachnutzbarkeit:** Alle Zwischenergebnisse bleiben erhalten. Wenn in Zukunft neue Projekte an unsere Arbeit anknüpfen, können sie die Repository-Historie einsehen und verstehen, *warum* wir bestimmte Entscheidungen getroffen haben. Unsere offen lizenzierten Materialien lassen sich direkt übernehmen oder adaptieren, ohne rechtliche Hürden. Durch die Versionierung ist auch Zitierbarkeit gegeben (ein bestimmter Stand der Materialien kann per Commit-ID referenziert werden, was in wissenschaftlichen Kontexten wichtig ist – sogar ein BibTeX-Zitat des gesamten Repos ist generierbar. Außerdem werden wichtige Ergebnisse zusätzlich auf Dauerarchiven (z.B. Zenodo, github, WLO, Edusharing, OSF) veröffentlicht, was in der Pipeline schon vorgesehen ist. Somit sichern wir, dass die Arbeit von FOERBICO über das Projektende hinaus offen verfügbar bleibt.
+
+Kurzum, FOERBICO will eine *offene Projektkultur* leben: interne Transparenz (im Team) geht nahtlos über in externe Transparenz (gegenüber der Community). Dieses intendierte OEP-Modell fördert nicht nur bessere Materialien, sondern auch eine Haltung der Zusammenarbeit und des Teilens, die für offene Bildung unabdingbar ist.
+
+Zum Abschluss sei betont: **„Offenheit“ bedeutet für uns auch ständige Verbesserung**. Wir evaluieren unsere Arbeitsprozesse fortlaufend. Feedback – sowohl intern als auch von externen Beobachtern – nehmen wir ernst, um unsere Kollaborationspraktiken zu optimieren. So wächst FOERBICO nicht nur an seinen inhaltlichen Ergebnissen, sondern auch daran, *wie* wir diese Ergebnisse erzielen. Die transparente Dokumentation unserer Arbeitsweise (wie in diesem Beitrag) ist Teil dieses Reflexionsprozesses und soll als Referenz für ähnliche Projekte dienen, die Open Educational Practices implementieren möchten.
+
+Durch diese offene, git-basierte Arbeitsorganisation ist es uns gelungen, über Institutions- und Fachgrenzen hinweg effizient zusammenzuarbeiten. **“So arbeiten wir”** – und wir laden alle ein, sich davon inspirieren zu lassen und mitzumachen, um offene Bildungsressourcen gemeinsam voranzubringen. 
+
+---
+
+**Quellen:** Die oben beschriebenen Abläufe und Beispiele beziehen sich auf das [git-Repositorium *Comenius-Institut/FOERBICO*](https://git.rpi-virtuell.de/Comenius-Institut/FOERBICO/) und dessen öffentlich einsehbare Repository-Daten (Issues, Commits, Dateien). Relevante Ausschnitte sind direkt im Text referenziert, um die Transparenz unserer Beschreibung zu unterstreichen.

Website/content/posts/2025-04-11-OER-Hochschulreihe-Teil-3/index.md

@@ -1,163 +0,0 @@
----
-#commonMetadata:
-'@context': https://schema.org/
-creativeWorkStatus: Published
-type: LearningResource
-name: >-
-  Rückblick auf Teil 3 der Online-Fortbildungsreihe zu OER in der Hochschullehre
-  für Religionspädagogik & Theologie: : OER selbst erstellen und teilen
-description: >-
-  In Teil 3 der Online-Fortbildungsreihe "OER in der Hochschullehre
-  für Religionspädagogik & Theologie" wurden Grundlagen für die
-  Erstellung und Verwendung von OER, technische Tools und
-  Veröffentlichungsmöglichkeiten vorgestellt und diskutiert.
-  Unter der Leitung von Dr. Laura Mößle (Goethe-Universität Frankfurt),
-  Corinna Ullmann und Jörg Lohrer (beide Comenius-Institut) ging es verstärkt darum:
-  Was gilt es zu beachten, wenn OER an der Hochschule entwickelt und
-  veröffentlicht werden?
-license: https://creativecommons.org/licenses/by/4.0/deed.de
-id: https://oer.community/oer-fortbildungsreihe-3
-creator:
-  - givenName: Laura
-    familyName: Mößle
-    id: https://orcid.org/0000-0001-5255-8063
-    type: Person
-    affiliation:
-      name: Johann Wolfgang Goethe-Universität Frankfurt
-      id: https://ror.org/04cvxnb49
-      type: Organization
-  - givenName: Jörg
-    familyName: Lohrer
-    id: https://orcid.org/0000-0002-9282-0406
-    type: Person
-    affiliation:
-      name: Comenius-Institut
-      id: https://ror.org/025e8aw85
-      type: Organization
-keywords:
-  - OER
-  - OEP
-  - Hochschuldidaktik
-  - Theologie
-  - CC-Lizenzen
-  - Rechtsfragen
-  - Lizenzen
-  - Religionspädagogik
-  - Theologie
-  - Qualitätskriterien
-inLanguage:
-  - de
-about:
-  - https://w3id.org/kim/hochschulfaechersystematik/n02
-  - https://w3id.org/kim/hochschulfaechersystematik/n03
-learningResourceType:
-  - https://w3id.org/kim/hcrt/text
-  - https://w3id.org/kim/hcrt/web_page
-educationalLevel:
-  - https://w3id.org/kim/educationalLevel/level_A
-datePublished: '2025-04-11'
-#staticSiteGenerator:
-author:
-  - Laura Mößle
-title: 'Rückblick zur OER-Fortbildungsreihe Teil 3: OER selbst erstellen und teilen'
-cover:
-  relative: true
-  image: classroom.jpg
-  hiddenInSingle: false
-summary: |
-  Offene Bildungsressourcen (Open Educational Resources, OER) sind eine
-  wertvolle Bereicherung für die Hochschullehre. Worauf es bei der Erstellung
-  und dem Teilen von OER ankommt, erläuterten Dr. Laura Mößle
-  (Goethe-Universität Frankfurt), Corinna Ullmann und Jörg Lohrer (Comenius-Institut).
-url: oer-fortbildungsreihe-3
-tags:
-  - OER
-  - OEP
-  - Hochschuldidaktik
-  - Theologie
-  - CC-Lizenzen
-  - Rechtsfragen
-  - Lizenzen
-  - Religionspädagogik
-  - Theologie
-  - Qualitätskriterien
----
-
-## Grundlagen zur Erstellung von OER
-
-Im dritten Workshop der mehrteiligen Workshop-Reihe starteten wir zunächst mit den Grundlagen zur Erstellung von OER. Hierbei spielt die korrekte Angabe von Quellen eine zentrale Rolle. Ein bewährtes Hilfsmittel hierfür ist die **TULLU-V-Regel** (auch als **[TULLUBA-Regel](https://open-educational-resources.de/oer-tullu-regel/)** bekannt), die sich insbesondere für Materialien mit Creative-Commons-Lizenzen etabliert hat.
-
-Die Regel steht für folgende Bestandteile:
-
-- **T – Titel**  
-  Die Angabe des Werktitels ist nur bei älteren Lizenzversionen (vor CC 4.0) verpflichtend, und auch dann nur, wenn tatsächlich ein Titel genannt wird.
-
-- **U – Urheber:in**  
-  Der Name der/des Urheber:in bzw. der Profilname auf einer Plattform (z. B. Flickr, Wikimedia Commons) sollte angegeben werden. Ein Link zum Profil ist eine freundliche Ergänzung, aber rechtlich nicht zwingend erforderlich.
-
-- **L – Lizenz**  
-  Die verwendete Creative-Commons-Lizenz ist präzise zu benennen, inklusive vollständigem Namen und Abkürzung (z. B. *CC BY 4.0*). Zudem ist ein **direkter Link zur Lizenzurkunde** anzugeben, damit die Lizenzbedingungen für Dritte nachvollziehbar sind.
-
-- **L – Link zur Quelle**  
-  Der Ursprungsort bzw. die URL, unter der das Originalmaterial veröffentlicht wurde, sollte ebenfalls aufgeführt werden. Diese Angabe wird in der Regel mit dem Titel oder dem Materialnamen verknüpft.
-
-- **U – Ursprungsort des Bildes/ Materials**  
-  Der genaue Fundort des Materials (z. B. Plattform oder Webseite) sollte ebenfalls genannt werden.
-
-- **V – Veränderungen**  
-  Seit der Version 4.0 der CC-Lizenzen ist es verpflichtend, alle vorgenommenen **inhaltlichen Veränderungen** am Material anzugeben. Dazu zählen z. B. Umschreibungen, Neuanordnungen, Übersetzungen, Kürzungen, gestalterische Bearbeitungen oder auch das Zuschneiden von Bildern.
-
-Diese Regel unterstützt dabei, CC-lizenzierte Inhalte  korrekt auszuweisen und transparent im eigenen Material darzustellen.
-
-## Rechtliche Aspekte bei der Erstellung von OER
-
-Die Erstellung von OER erfordert nicht nur didaktisches Gespür, sondern auch ein sorgfältiges Auge für rechtliche Rahmenbedingungen. Im Idealfall bestehen OER vollständig aus selbst erstellten oder rechtlich unbedenklichen, offen lizenzierten Inhalten, wodurch es nicht zu einer Verletzung fremder Urheberrechte kommt. Sollte dies nicht möglich sein, müssen geschützte Inhalte entweder durch offene Alternativen ersetzt oder in Übereinstimmung mit ihrer jeweiligen Lizenz korrekt gekennzeichnet werden.
-
-Hierbei ist die Einhaltung der **TULLU-V-Regel** zentral, die die korrekte Namensnennung bei Creative-Commons-lizenziertem Material vorgibt. Ebenso sollte frühzeitig geklärt werden, in wessen Namen – etwa als Team, Projektgruppe oder Institution – eine eventuelle Namensnennung erfolgen soll.
-
-Für das gesamte Material ist außerdem eine passende [Creative-Commons-Lizenz](https://oer.community/oer-fortbildungsreihe-2/) auszuwählen, die den gewünschten Nutzungsumfang abbildet. Besonders zu beachten ist hierbei die „ND“-Lizenz (No Derivatives), die keine Bearbeitung oder Vermischung mit anderen Materialien erlaubt und somit für neu kombinierte Inhalte nicht geeignet ist. Jegliche urheberrechtlich geschützte Elemente wie Videos, Grafiken, Audiodateien, Schriften oder Logos müssen, sofern sie nicht offen lizenziert sind, entweder ausgetauscht oder eindeutig von der Lizenzierung des restlichen Materials ausgenommen werden.
-
-Über die rechtlichen Anforderungen hinaus empfiehlt es sich, OER nicht als abgeschlossene Produkte zu verstehen, sondern als Teil eines iterativen Entwicklungsprozesses. Rückmeldung durch Kolleg:innen oder Fachleute vor der Veröffentlichung kann nicht nur rechtliche Schwachstellen sichtbar machen, sondern auch die inhaltliche und didaktische Qualität des Materials verbessern. 
-
-## OER-Gestaltung mit H5P
-
-Im Anschluss an die theoretische Auseinandersetzung mit OER konnten wir einen praxisnahen Einblick in die Gestaltung mit H5P geben. H5P (HTML5 Package) ist ein Open-Source-Tool zur Erstellung interaktiver und multimedial ansprechender Lerninhalte. Es ermöglicht eine breite Palette an Inhaltstypen, z. B. interaktive Videos, Multiple-Choice-Aufgaben, Drag-and-Drop-Übungen oder Zeitleisten, die ohne Programmierkenntnisse direkt im Browser erstellt werden können.
-
-Besonderes Augenmerk legten wir auf die **Course Presentation**, ein H5P-Inhaltstyp, der die Erstellung von Folienpräsentationen mit eingebetteten interaktiven Elementen erlaubt. Damit lassen sich klassische Lehrmaterialien dynamisch aufbereiten und um formative Übungseinheiten ergänzen.
-
-Über die Plattform [einstiegh5p.de](https://einstiegh5p.de/) wurde den Teilnehmenden demonstriert, wie H5P-Inhalte erstellt, gespeichert und später bearbeitet werden können. Schritt für Schritt wurde gezeigt:
-
-- wie man ein neues H5P-Element anlegt,
-- welche Inhaltstypen zur Verfügung stehen,
-- wie Medien (z. B. Bilder, Videos, Audio) eingebunden werden können.
-
-Die Inhalte können direkt auf einer Lernplattform oder Website eingebettet werden. OER mit interaktiven Elementen wie H5P bietet großes Potenzial für eine aktivierende und anschlussfähige Lehrpraxis.
-
-## Verbreitung von OER: Wo und wie veröffentlichen?
-
-Ein zentraler Aspekt der Arbeit mit OER ist nicht nur deren Erstellung, sondern auch deren gezielte Verbreitung. Die Sichtbarkeit qualitativ hochwertiger, offener Bildungsmaterialien erhöht ihren pädagogischen Nutzen und ermöglicht die Weiterentwicklung durch andere. In Workshoo wurden daher einige zentrale Plattformen vorgestellt, die sich für die Veröffentlichung von OER eignen, insbesondere mit Blick auf den schulischen und hochschulischen Bereich sowie die Religionspädagogik.
-
-### OERSI – Open Educational Resources Search Index
-
-[OERSI](https://oersi.org/resources/) ist eine fächerübergreifende Suchmaschine, die freie Bildungsmaterialien aus verschiedenen Repositorien im Hochschulbereich bündelt und durchsuchbar macht. Wer eigene OER veröffentlichen möchte, profitiert hier von einer besonders hohen Sichtbarkeit. Die Veröffentlichung erfolgt jedoch **nicht direkt über OERSI**, sondern über ein angebundenes Repositorium, das in den Index integriert ist.
-
-### Wir lernen online (WLO)
-
-Die Plattform [„Wir lernen online“](https://suche.wirlernenonline.de/search/de/search?filters=%7B%22discipline%22:%5B%22http:%2F%2Fw3id.org%2Fopeneduhub%2Fvocabs%2Fdiscipline%2F520%22%5D%7D) sammelt freie Bildungsressourcen für eine Vielzahl von Fächern – darunter auch Religion. Materialien können über ein [Online-Formular](https://wirlernenonline.de/fachportalinhalte-vorschlagen/?type=material&headline=Fachportal&pageDiscipline=Religion) eingereicht werden. Nach einer redaktionellen Prüfung werden die Inhalte über das **Fachportal Religion** öffentlich zugänglich gemacht. Diese Plattform eignet sich besonders für Lehrkräfte, die ihre OER veröffentlichen möchten.
-
-### Twillo – OER-Infrastruktur in Niedersachsen
-
-[Twillo](https://www.twillo.de) ist eine landesweite OER-Infrastruktur, die auf die Hochschulbildung in Niedersachsen ausgerichtet ist. Die Veröffentlichung eigener Materialien erfolgt über Partner-Repositorien, die technisch und organisatorisch mit Twillo verknüpft sind. Durch diese Vernetzung werden die Inhalte auf einer zentralen Plattform sichtbar gemacht und können in größere Zusammenhänge eingebettet werden.
-
-### Relilab – OER für die Religionspädagogik
-
-[Relilab](https://relilab.org/category/formate-asynchron/lernmodul/) ist eine digitale Plattform zur Förderung religionspädagogischer Zusammenarbeit. Hier können Lehrkräfte eigene OER bereitstellen, sich an kollaborativen Projekten beteiligen oder Fortbildungsangebote nutzen. Alle Inhalte stehen unter der offenen Lizenz **CC BY** und eignen sich besonders zur Weiterentwicklung sowie zur gezielten fachlichen Verbreitung religionspädagogischer Inhalte. 
-
-## OER-Verbreitung mit git
-Mit dem [**OER GitHub Tutorial**](https://oersi.org/resources/aHR0cHM6Ly9saWFzY3JpcHQuZ2l0aHViLmlvL2NvdXJzZS8_aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL3JwaS12aXJ0dWVsbC9vZXItZ2l0aHViLXR1dG9yaWFsLWxpYXNjcmlwdC9tYWluL3R1dG9yaWFsLm1kIzE=) und dem [**OER Metadatenformular**](https://oersi.gitlab.io/metadata-form/metadata-generator.html) stehen zwei besonders praxisorientierte Werkzeuge zur Verfügung. Das GitHub-Tutorial erleichtert Einsteiger:innen den Zugang zur Veröffentlichung, das Metadatenformular ist ein Unterstützungsinstrument um konform zu den Metadatenstandards zu publizieren.
-Im Workshop haben wir die Erfassung und Veröffentlichung an einem Beispiel durchgespielt. Zur besseren Nachvollziehbarkeit und gleichzeitig als Anleitung dokumentieren wir hier, wie dies in zwei Schritten sofort selbst umsetzbar ist. 
-1. Für die beispielhafte CC-BY-Publikation ["Konfi-Arbeit in und nach der Corona-Pandemie"](https://www.degruyterbrill.com/document/doi/10.14315/9783641331566/html), die bislang weder auf OERSI noch Twillo indexiert und somit auch hier noch nicht auffindbar war, erfassen wir die Metadaten mit dem [Metadatenformular](https://oersi.gitlab.io/metadata-form/metadata-generator.html) von OERSI und stellen diese dann [hier via gitlab als yml bereit](https://gitlab.com/comenius-institut/foerbico/oersi-datensatz/-/blob/main/resource_metadata/2025-04-08-konfi-arbeit-corona.yml).     
-2. OERSI indexiert automatisch und zeigt nun [bei einer Suche nach "Konfi-Arbeit" diesen neuen Eintrag](https://oersi.org/resources/aHR0cHM6Ly9kb2kub3JnLzEwLjE0MzE1Lzk3ODM2NDEzMzE1NjY=) an und [auch bei Twillo wird man nun hier fündig](https://www.twillo.de/oer/web/suche/?search=%22Konfi-Arbeit+in+und+nach+der+Corona-Pandemie%22).
-
-So konnten wir in unserem Workshop dieses "Proof-of-Concept" direkt exemplarisch live umsetzen und als Ergebnis den Workflow nun hier nachnutzbar dokumentieren.
-Zögert nicht, uns zu kontaktieren, wenn ihr Fragen habt oder Unterstützung braucht, um die religionsbezogene Hochschullehre, die bisher nur ansatzweise unter freien Lizenzen in OER-Suchportalen zu finden ist, gemeinsam zu erweitern!

Website/content/posts/2025-04-15-open-net/index.md

@@ -1,106 +0,0 @@
----
-#commonMetadata:
-'@context': https://schema.org/
-type: ScholarlyArticle
-id: https://oer.community/evangelisches-labor
-name: Religionsbezogene Bildung und evangelische Publizistik - Auf dem Weg zu einem offenen Netzwerk als neue Ermöglichungsstruktur
-description: >-
-  Ein Gespräch zwischen Greg Elson (GEP) und Jörg Lohrer (Comenius-Institut)
-  eröffnet Perspektiven auf dezentrale Bildungs- und Medienarchitekturen im
-  protestantischen Raum. Es geht um die Befreiung der Daten, die Ermöglichung
-  partizipativer Infrastrukturen und das gemeinsame Entwerfen eines offenen
-  Netzwerkraums - dem Evangelischen Labor oder eines Open Net.
-inLanguage: de
-license: https://creativecommons.org/licenses/by/4.0/
-creator:
-  - givenName: Jörg
-    familyName: Lohrer
-    id: https://orcid.org/0000-0002-9282-0406
-    type: Person
-    affiliation:
-      name: Comenius-Institut
-      id: https://ror.org/025e8aw85
-      type: Organization
-  - givenName: Greg
-    familyName: Elson
-    type: Person
-    affiliation:
-      name: Gemeinschaftswerk der Evangelischen Publizistik
-      type: Organization
-keywords:
-  - Netzwerkarchitektur
-  - Protokollbasiertes Denken
-  - OpenNet
-  - Partizipation
-  - Publishing-Cockpit
-  - Evangelisches Labor
-  - Interoperabilität
-about:
-  - https://w3id.org/kim/hochschulfaechersystematik/n052
-  - https://w3id.org/kim/hochschulfaechersystematik/n079
-  - https://w3id.org/kim/hochschulfaechersystematik/n544
-image: https://oer.community/evangelisches-labor/greg-und-joerg-we-are-open.png
-learningResourceType:
-  - https://w3id.org/kim/hcrt/article
-educationalLevel:
-  - https://w3id.org/kim/educationalLevel/level_A
-datePublished: '2025-04-15'
-#staticSiteGenerator:
-author:
-  - Jörg Lohrer
-  - Greg Elson
-title: Religionsbezogene Bildung und evangelische Publizistik - Auf dem Weg zu einem offenen Netzwerk als neue Ermöglichungsstruktur
-cover:
-  relative: true
-  image: greg-und-joerg-we-are-open.png
-  caption: "Greg Elson (Gemeinschaftswerk evangelische Publizistik) und Jörg Lohrer (Comenius-Institut) mit Schriftzug 'We are open' - Screenshot Zoom-Videokonferenz)"
-summary: >-
-  Wie könnte ein evangelisches Labor aussehen, das dezentrale digitale Infrastrukturen
-  für Bildung und Publizistik ermöglicht? Ein exploratives Gespräch zwischen Greg Elson (GEP)
-  und Jörg Lohrer (Comenius-Institut) eröffnet Möglichkeitsräume und skizziert das
-  Potenzial vernetzter Zukunft im protestantischen Bildungsraum.
-url: evangelisches-labor
-tags:
-  - Digitalisierung
-  - Religion und Medien
-  - Vernetzung
-  - Plattformen
-  - OER
-  - UX Design
----
-
-## Vom Gemeindebrief zur Protokollarchitektur: Wie sich Bildungsräume vernetzen lassen
-
-Was zunächst als Dialog über IT-Architekturen begann, entwickelte sich zu einer dichten Exploration gemeinsamer Möglichkeitsräume: Greg Elson und Jörg Lohrer beleuchten in ihrem Gespräch die Zukunft evangelischer Bildungs- und Medienarbeit, indem sie **dezentrale Infrastrukturen** und **offene Netzwerkkonzepte** diskutieren. 
-Die beiden Gesprächspartner fokussieren sich dabei auf die **Befreiung von Daten** und die Auflösung proprietärer Content-Management-Systeme, die vielfach Inhalte verkapseln und kreative Zugänge blockieren. Gerade an diesem Punkt wird deutlich, wie sehr eine Offenlegung von Formaten und eine protokollbasierte Architektur (z. B. über JSON-Formate oder Nostr-Relays) neue Lern- und Publikationsräume befördern kann. Erst wenn Daten interoperabel und frei zugänglich sind, entfaltet sich das Potenzial für **Open Educational Resources (OER)**, **Open Educational Practices (OEP)** sowie eine innovationsfreundliche, experimentelle Medienarbeit im protestantischen Raum.
-
-## Perspektivenwechsel: Vom System zur Schnittstelle
-
-Zentral für diesen Wandel ist ein Perspektivenwechsel: Zukünftige Bildungs- und Mediennetzwerke entwickeln sich nicht mehr auf Basis geschlossener Systemarchitekturen, sondern durch **anschlussfähige Schnittstellen**, die von Anfang an offen gedacht sind. Entsprechend ist die Rede von einer konsequenten Trennung zwischen Inhalts- und Metadatenebene, die sich an überführbaren Standards orientieren soll. Ähnlich wie in anderen föderalen Bildungsinitiativen ist die Zielrichtung deutlich: weg von reinen Silo-Systemen und proprietären Softwarelösungen, hin zu **partizipativen Infrastrukturen**, die das Potenzial asynchroner Zusammenarbeit auch von Ehrenamtlichen noch besser zur Entfaltung bringen zu können.
-
-Dieser dezentrale Ansatz in dem ein "Evangelisches Labor" oder „Open Net“ als **Inkubator** und **Ermöglichungsstruktur** seine Wirkung entfalten könnte, impliziert eine neue Sicht auf Kirche und Medien. Eine Inkubationsumgebung, die Innovationen bewusst fördert und Räume für Experimente, Prototypen und Netzwerkbildung wird gemeinsam als echter Zugewinn gesehen. Statt Inhalte kontrollieren zu wollen, fördern Schnittstellenorientierung und offene Datenhaltung die gemeinsame Weiterentwicklung und das Teilen von Wissensressourcen. Dies gilt für den Religionsunterricht und seine digitalen Materialien ebenso wie für Angebote kirchlicher Publizistik.
-
-Der Projektname „Open Net“ fiel uns dabei ebenfalls ein – als Denkrahmen, als Arbeitstitel, als mögliches Vehikel für gemeinsames Sichtbarwerden. Was wäre, wenn wir nicht in „Landkarten“ evangelische Websites dokumentieren, sondern auch deren Funktionen, Verbindungslinien und Wechselwirkungen sichtbar würden? In bisherigen Bestrebungen wurden vereinzelt geobasierte Karten oder Auflistungen evangelischer Angebote geschaffen, jedoch fehlt dabei häufig die analytische Verknüpfung, soziale Graphen, und somit den eigentlichen Netzwerkcharakter abbildet. „The map is not the territory“ – dieser Satz des Philosophen Alfred Korzybski scheint uns gleichsam Leitmotiv einer Entwicklungsperspektive, die nicht nur die Repräsentation religionsbezogener Bildung und Mediendistribution im Blick hat sondern vielmehr den Fokus auf die gemeinschaftlichen Erarbeitungsprozesse und kooperativen Kompetenzaufbau in einer Kultur der Digitalität verlagert.
-
-## Die Befreiung der Daten
-
-„Bevor wir mit KI anfangen können, müssen wir erstmal die Daten befreien,“ so bringt es Greg auf den Punkt. In vielen kirchlichen Kontexten werden Inhalte noch immer in proprietären Systemen gefangen gehalten. Weil diese stark versäult sind, bleibt die Umsetzung innovativer Formate oder kollaborativer Lern- und Publikationsprojekte häufig in den Startlöchern stecken. Mit „Befreiung der Daten“ ist nicht nur ein technischer Schritt gemeint, sondern eine prinzipielle Neuorganisation: Inhalte sollen maschinenlesbar, interoperabel und möglichst offen zugänglich sein, um echte Partizipation zu gewährleisten. Erst auf dieser Grundlage lohnt es sich, umfassend über **künstliche Intelligenz**, **empfehlungsbasierte Systeme** oder **semantische Suchverfahren** nachzudenken.
-
-Diese Offenheit und Öffentlichkeit bedürfen jedoch verbindlicher Vereinbarungen in Bezug auf **Metadaten-Schemata**, **Lizenzfragen** (z. B. Creative-Commons-Regelungen) und **föderale Standards** für evangelische Bildungs- und Publizistikprojekte. Erst wenn Interessierte sich in einer Community auf gemeinsame Metadaten und Schnittstellen einigen, entsteht ein durchweg partizipatives, lernendes Netzwerk.
-
-## Rollen, Broker und Beteiligungspotenziale
-
-Beide Gesprächspartner reflektierten ihre Rollen – nicht als Projektkoordinatoren klassischer Prägung, sondern als **Broker** in emergenten Netzwerken. Es geht um Antizipation, Resonanz, Enablement. Greg betonte den Bedarf an UX-Design, das niedrigschwellig Zugänge schafft. Jörg verwies auf das Potenzial von Ehrenamtlichen, Pensionierten oder Menschen in Care-Situationen: „Die digitalen Netzwerklogiken könnte asynchrone Beteiligung auch für jene ermöglichen, deren aktive Teilgabe in hierarchisch organisierten Prozessen und synchroner Präsenz bislang behindert wurde.“
-
-## Rechtsform, Vertrauensräume und föderales Commitment
-
-Damit aus Ideen tragfähige Strukturen entstehen, braucht es auch institutionelle Rückbindung. Es wurde überlegt, wie eine geeignete Rechtsform aussehen könnte, um das Evangelische Labor oder einen Open Net Inkubator langfristig zu sichern – nicht als zentrales Organ, sondern als **vernetzenden Hub** mit föderaler Legitimität. Vertrauen, nicht Kontrolle, soll das tragende Prinzip sein.
-
-## Ausblick: Das zukünftig Mögliche
-
-„Das eigentlich Wirkliche ist das zukünftig Mögliche“. Unsere Ideen stehen noch am Anfang – als Idee, als Narrativ, als Bewegung. Aber es wächst, mit jeder Resonanz, jeder Gesprächseinladung, jeder Community, die sich anschließt. Der nächste Schritt? Vielleicht erste Erprobungen von Netzwerkprotokollen (z.B. Nostr). Vielleicht ein Mitmach-Manifest. Vielleicht nur ein Icon oder Symbol. Hauptsache: offen.
-
----
-
-> „Wir wollen nicht durch Geschlossenheit ins Breite, sondern durch Breite zu skalierbarer Beteiligung.“ – Jörg  
-> „Ein Netzwerk ist nur so stark wie die Beziehungen, die es trägt.“ – Greg