Merge pull request 'change-studientag' (#4) from change-studientag into main

Reviewed-on: #4

Anmeldung-Keycloak.md

@@ -0,0 +1,16 @@
+# Wie kann ich mich bei Git mit Keycloack anmelden?
+
+## Schritt 1: Öffne https://git.rpi-virtuell.de/ und klicke auf den Button "Anmelden" oben rechts
+
+![](https://pad.gwdg.de/uploads/bf2a7a78-c09b-4d5e-a8d9-8159d864f330.png)
+
+## Schritt 2: Wähle "Anmelden mit Keycloack"
+
+![](https://pad.gwdg.de/uploads/bbc23296-8378-42e3-bda0-3765fcb04bdc.png)
+
+## Schritt 3: Wähle "Anmelden mit Konto von rpi-virtuell"
+
+![](https://pad.gwdg.de/uploads/90048f4e-f86a-46a9-b0dd-116f111bc313.png)
+
+## Schritt 4: Gebe deine Zugangsdaten ein und melde dich an
+

Lables-und-Tags.md

@@ -0,0 +1,3 @@
+# Was sind Labels, was sind Tags und wie unterscheiden sie sich?
+
+Hier erfährst du, was Labels und Tags sind, was der Unterschied ist und wie du sie hinzufügen und z.B. in Issues einbinden kannst.

einführung-issues.md

@@ -0,0 +1,43 @@
+# Was ist ein Issue?
+
+Issues sind Elemente, die in einem Repository erstellt werden können, um Arbeit zu planen, zu besprechen und nachzuverfolgen. Sie sind einfach zu erstellen und flexibel für eine Vielzahl von Szenarien geeignet. Issues können erstellt werden, um Feedback zu geben oder zu erhalten, an Ideen oder Aufgaben zusammenzuarbeiten und öffentlich mit anderen zu einem Thema bzw. einer Fragestellung zu kommunizieren. 
+
+# Wie erstelle ich ein Issue?
+
+In jedem Repository werden die dazugehörigen Issues angezeigt:
+
+![](https://pad.gwdg.de/uploads/796e6aa8-c7ee-4b20-8e74-e438f632e773.png)
+
+Wenn man "Issues" anklickt, werden alle offenen Issues angezeigt. Wenn ein neues Issue angelegt werden soll, kann man auf den Button neues Issue klicken:
+
+![](https://pad.gwdg.de/uploads/7f61f985-ea11-462f-a065-27f994a888ba.png)
+
+Nun kann das Issue angelegt werden:
+
+![](https://pad.gwdg.de/uploads/e7c6a2f5-f758-42ba-b81f-ffc9fd030109.png)
+
+Trage dazu einen Titel mit der jeweiligen Aufgabe, Herausforderung oder Fragestellung ein, z.B. "Test-Issue für Git anlegen". Nun kannst du im Kommentarfeld noch eine Beschreibung hinterlassen und durch @-Mention Personen markieren, für die das Issue relevant ist oder die Aufgaben übernehmen sollen oder an die du Rückfragen hast. Theoretisch können auch Zuständige zugewiesen werden, netterweise fragt man die jeweilige Person vorher, wie die Kapazitäten sind und ob sie die Aufgabe übernehmen kann / möchte, damit nicht eine Person am Ende alle Issues zugewiesen bekomm. Personen können sich auch selbst als Zuständige eintragen. So können Aufgaben im Team verteilt werden. 
+
+### Hinweis:
+
+Beachte, dass andere Personen mit dem Titel etwas anfangen können oder durch die Beschreibung und die Labels nachvollziehen können, worauf sich das Issue bezieht, sonst wird die Zusammenarbeit schwierig. Falls der Titel unverständlich bzw. unpräzise ist, kann er auch im Nachhinein noch bearbeitet werden. Klicke dazu oben rechts in der Ecke auf den grauen Button "Bearbeiten" (neben dem orangenen Button "Neues Issue").
+
+Man kann die Issues auch mit Labels markieren, um sie zu kategorisieren. Es kann z.B. das Label "contribution-welcome" gesetzt werden, um andere Personen zur Beteiligung und offenen Zusammenarbeit zu ermutigen. Durch Labels wie z.B. "Technischer Support" können auch Zuständigkeiten besser zugeordnet werden (z.B. Technikteam vom CI).
+
+### Hinweis:
+
+Labels sind keine Tags! Es können auch Tags vergeben werden. Tags sind ein Werkzeug zur Markierung wichtiger Punkte in der Commit-Historie (z.B. v1 für Version 1 eines Dokumentes etc.), während Labels dazu dienen, Aufgaben und Tickets innerhalb von Projekten zu kategorisieren und zu priorisieren. Beide Konzepte sind essenziell, um große und komplexe Projekte zu verwalten. Durch das Tagging werden Issues also einem bestimmten Arbeitsschritt zugeordnet (also z.B. Dokumentation V1), das Label kategorisiert den Arbeitsauftrag also z.B. "high-priority" und "documentation" mit der Beschreibung "Kennzeichnet die Notwendigkeit für Verbesserungen oder Ergänzungen der Dokumentation". Wie Labels und Tags hinzugefügt werden können, erfährst du [hier](Link zu Dok Labels & Tags). 
+
+Man kann Issues auch mit Meilensteinen oder Projekten verknüpfen, um sie besser zuzuordnen und den Stand der Projekte anzuzeigen (was wurde bereits bearbeitet, was ist noch zu tun, welche Meilensteine wurden erreicht / sind noch offen usw.). Zudem können ein Fälligkeitsdatum und die geplante Arbeitszeit, die für die Bearbeitung des Issues benötigt wird, eingetragen werden und/oder die Arbeitszeit wird gestoppt. Durch die Zeiterfassung wird nachvollziehbar, wie lange und wann Personen an einem Issue gearbeitet haben.
+
+Issues können auf referenziert und damit auf andere Aufgaben bezogen werden bzw. mit anderen Issues verknüpft werden. Das ist insbesondere bei Arbeitspaketen mit aufeinander bezogenen Aufgaben sinnvoll.
+
+Sind Aufgaben erledigt, Fragen geklärt oder Herausforderungen gemeistert, können Issues geschlossen werden. Das ist für den Workflow wichtig, damit sich die Issues nicht häufen und es nicht unübersichtlich wird! 
+
+Dazu kannst du entweder auf Issue schließen klicken oder falls ein Issue versehentlich erstellt wurde, es komplett löschen:
+
+![](https://pad.gwdg.de/uploads/b5867158-d2f8-4064-858c-86a9b06f51cf.png)
+
+Alle geschlossenen Issues findet man in der Übersicht, bei Bedarf können sie auch wieder geöffnet werden:
+
+![](https://pad.gwdg.de/uploads/7a9a2a82-0084-4d29-9550-f87702e04549.png)

git-studientag.md

@@ -73,7 +73,7 @@ am 23.Juli 2024 ab 9 Uhr in https://comenius.de/zoom
 8. [Quellennachweise](#quellennachweise)
 
 ## Registrierung und Anmeldung (30 Minuten)
-- Teilnehmer registrieren sich und melden sich via Keycloak an
+- Teilnehmende registrieren sich und melden sich via Keycloak an (siehe [hier](https://git.rpi-virtuell.de/Comenius-Institut/git/src/branch/change-studientag/Anmeldung-Keycloak.md))
 - Kurze Einführung in die Plattform und den Tagesablauf
 
 ## Erwartungsabfrage (45 Minuten)
@@ -96,13 +96,13 @@ Teilnehmer arbeiten bedarfsorientiert an ihren Erwartungen, indem sie Issues bea
 - Evtl. Übungen zu Branching, Merging und Pull Requests
 
 ## Praxisphase: Issues bearbeiten und schließen
-Teilnehmer bearbeiten die offenen Issues gemeinschaftlich und dokumentieren ihre Lösungen in Markdown-Dateien. Sie schließen die Issues, wenn sie abgeschlossen sind.
+Teilnehmende bearbeiten die offenen Issues gemeinschaftlich und dokumentieren ihre Lösungen in Markdown-Dateien. Sie schließen die Issues, wenn sie abgeschlossen sind.
 
 ## Mittagspause (60 Minuten)
 
 ## Bedarfsorientierte Workshops (120 Minuten)
 - Parallel laufende Sessions zu verschiedenen Git-Themen basierend auf den Issues
-- Teilnehmer wählen ihre Sessions nach Interesse
+- Teilnehmende wählen ihre Sessions nach Interesse
 
 ## Gemeinsames Wissensmanagement (60 Minuten)
 - Zusammenführen der erarbeiteten Inhalte
@@ -117,10 +117,10 @@ Teilnehmer bearbeiten die offenen Issues gemeinschaftlich und dokumentieren ihre
 ## Variationsmöglichkeiten
 
 ### Themenspezifische Gruppen
-Teilnehmer werden in themenspezifische Gruppen eingeteilt (z.B. Git Basics, Fortgeschrittene Git-Funktionen, Markdown-Syntax).
+Teilnehmende werden in themenspezifische Gruppen eingeteilt (z.B. Git Basics, Fortgeschrittene Git-Funktionen, Markdown-Syntax).
 
 ### Hackathon-Stil
-Ein Hackathon wird veranstaltet, bei dem die Teilnehmer innerhalb eines bestimmten Zeitrahmens so viele Issues wie möglich bearbeiten.
+Ein Hackathon wird veranstaltet, bei dem die Teilnehmende innerhalb eines bestimmten Zeitrahmens so viele Issues wie möglich bearbeiten.
 
 ### Gamification
 - Einführung eines Punktesystems für Beiträge und geschlossene Issues
@@ -142,14 +142,14 @@ Regelmäßige Feedback-Runden, in denen die Teilnehmer ihre Erfahrungen und Hera
 - "Branch-Strategie-Puzzle": Entwickeln einer komplexen Feature-Strategie
 
 ## Didaktische Tipps
-- **Vorbereitung**: Sicherstellen, dass alle Teilnehmer die erforderlichen Software-Tools installiert haben und Zugang zu den benötigten Tools (rpi-Konto, Keycloak-Anmeldung, Rechte in git) haben.
+- **Vorbereitung**: Sicherstellen, dass alle Teilnehmenden die erforderlichen Software-Tools installiert haben und Zugang zu den benötigten Tools (rpi-Konto, Keycloak-Anmeldung, Rechte in git) haben.
 - **Aktives Lernen**: Interaktive Methoden wie Pair Programming oder Peer Reviews nutzen. Viele praktische Übungen und Hands-on-Erfahrungen einbauen
 - Visualisierung: Diagramme und Grafiken zur Veranschaulichung von Git-Konzepten verwenden
 - Regelmäßige Pausen einplanen
-- **Anpassungsfähigkeit**: Flexibel sein und den Plan an die Bedürfnisse der Teilnehmer anpassen.
+- **Anpassungsfähigkeit**: Flexibel sein und den Plan an die Bedürfnisse der Teilnehmenden anpassen.
 - **Dokumentation**: Die Bedeutung der Dokumentation in Markdown betonen.
-- **Feedback**: Am Ende des Tages Feedback von den Teilnehmern sammeln, um zukünftige Veranstaltungen zu verbessern.
+- **Feedback**: Am Ende des Tages Feedback von den Teilnehmenden sammeln, um zukünftige Veranstaltungen zu verbessern.
-- Differenzierung: Zusatzressourcen für Fortgeschrittene und Unterstützung für Anfänger anbieten
+- **Differenzierung**: Zusatzressourcen für Fortgeschrittene und Unterstützung für Anfänger anbieten
 
 
 ## Quellennachweise