code-project-template/.gitlab/issue_templates/Release.md

<!-- 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"