From 6e60ef9d71187438d1391fe7304521696c83d434 Mon Sep 17 00:00:00 2001 From: Nicole Dresselhaus Date: Thu, 15 May 2025 10:34:44 +0200 Subject: [PATCH] added Release-Template --- .gitlab/issue_templates/Release.md | 49 ++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 .gitlab/issue_templates/Release.md diff --git a/.gitlab/issue_templates/Release.md b/.gitlab/issue_templates/Release.md new file mode 100644 index 0000000..d2f3f0a --- /dev/null +++ b/.gitlab/issue_templates/Release.md @@ -0,0 +1,49 @@ + + +## Issues + + + +## 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"