added Release-Template

.gitlab/issue_templates/Release.md

@@ -0,0 +1,49 @@
+<!-- use this template to plan a release. It should make sure you at least thought about things. -->
+
+## Issues
+
+<!-- Liste aller Issues, die seit dem letzten Release in diesem Code enthalten sind -->
+
+## Checklist
+
+- [ ] **Zielklärung:** Ist der Zweck der Software klar benannt und der
+      wissenschaftliche _Need_ begründet? (Falls nein, ergänzen: _Warum
+      existiert dieses Tool?_)
+- [ ] **Installation & Voraussetzungen:** Sind alle Schritte, um die Software
+      lauffähig zu machen, dokumentiert (inkl. Dependencies, evtl. mit
+      Installationsbefehlen)? Ist ersichtlich, welche Umgebung nötig ist (OS,
+      Hardware)?
+- [ ] **Grundlegende Nutzung:** Gibt es eine Anleitung oder Beispiele, wie man
+      die Software verwendet (Eingabe -> Ausgaben)? Ist mindestens ein typischer
+      Workflow beschrieben, idealerweise mit Beispielinput und -output?
+- [ ] **Optionen & Schnittstellen:** Falls relevant – sind alle wichtigen
+      Funktionen, Befehlsoptionen oder API-Methoden dokumentiert? (Nicht
+      unbedingt jede intern, aber alles, was ein Nutzer aufrufen könnte). Für
+      APIs: Sind Parameter und Rückgaben erläutert?
+- [ ] **Validierung & Einschränkungen:** Werden Annahmen und Grenzen der
+      Software genannt? Weiß ein*e Nutzer*in, welche Fälle nicht abgedeckt sind
+      oder worauf zu achten ist (z. B. Datenqualität, maximale Größen)?
+      Transparenz hier verhindert Frustration.
+- [ ] **Hintergrund & Referenzen:** Sind die wichtigsten konzeptionellen
+      Hintergründe oder Referenzen angegeben? (Z. B. theoretische Grundlagen,
+      Algorithmen, Literaturverweise). Das muss kein Essay sein, aber ein paar
+      Sätze + Referenzen schaffen Vertrauen in die wissenschaftliche Fundierung.
+- [ ] **Kontakt & Weiterführung:** Ist angegeben, wie man Hilfe bekommt oder
+      Fehler melden kann (Issue-Tracker, E-Mail)? Gibt es Hinweise für Beiträge
+      (falls erwünscht) oder zumindest die Information, wer die Autor\*innen
+      sind?
+- [ ] **Rechtliches & Zitation:** Liegt die Lizenz bei und wird sie genannt?
+      Sind Infos zum Zitieren der Software vorhanden (z. B. “Bitte zitieren Sie
+      DOI XYZ”)? Das stellt sicher, dass die Software nachnutzbar _und_
+      akademisch kreditiert wird.
+- [ ] **Aktualität & Version:** Entspricht die Dokumentation der aktuellen
+      Softwareversion? (Check: Versionsnummern, Datumsangaben). Veraltete Doku
+      kann schlimmer sein als keine – planen Sie also ein, die Doku mit jedem
+      Release kurz zu überprüfen.
+- [ ] **Konsistenz & Stil:** Wird ein einheitlicher Ton und Stil durchgehalten?
+      (z. B. durchgehende Verwendung gleicher Begriffe für Konzepte, Sprache
+      entweder Deutsch oder Englisch einheitlich je nach Zielgruppe). Kleinliche
+      Fehler (Tippfehler, kaputte Links) sind auszumerzen, da sie Nutzer
+      abschrecken.
+
+/label ~"documentation::releases"