Initial Code-Project-Template

.gitlab/changelog_config.yml

@@ -0,0 +1,39 @@
+---
+# Settings for generating changelogs using the GitLab API. See
+# https://docs.gitlab.com/ee/api/repositories.html#generate-changelog-data for
+# more information.
+categories:
+  added: Added
+  fixed: Fixed
+  changed: Changed
+  deprecated: Deprecated
+  removed: Removed
+  security: Security
+  performance: Performance
+  other: Other
+include_groups:
+  - Methodenlabor
+template: |
+  {% if categories %}
+  {% each categories %}
+  ### {{ title }} ({% if single_change %}1 change{% else %}{{ count }} changes{% end %})
+
+  {% each entries %}
+  - [{{ title }}]({{ commit.web_url }})\
+  {% if author.credit %} by {{ author.reference }}{% end %}\
+  {% if commit.trailers.MR %}\
+   ([merge request]({{ commit.trailers.MR }}))\
+  {% else %}\
+  {% if merge_request %}\
+   ([merge request]({{ merge_request.web_url }}))\
+  {% end %}\
+  {% end %}\
+
+  {% end %}
+
+  {% end %}
+  {% else %}
+  No changes.
+  {% end %}
+# The tag format for gitlab-org/gitlab is vX.Y.Z(-rcX). Releases are always without trailing -...
+tag_regex: '^v(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)$'

.gitlab/issue_templates/Bug.md

@@ -0,0 +1,26 @@
+### Summary
+
+<!-- Summarize the bug encountered concisely. -->
+
+### Steps to reproduce
+
+<!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. -->
+
+### What is the current _bug_ behavior?
+
+<!-- Describe what actually happens. -->
+
+### What is the expected _correct_ behavior?
+
+<!-- Describe what you should see instead. -->
+
+### Relevant logs and/or screenshots
+
+<!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code
+ as it's tough to read otherwise. -->
+
+### Possible fixes
+
+<!-- If you can, link to the line of code that might be responsible for the problem. -->
+
+/label ~"type::bug"

.gitlab/issue_templates/Decision Matrix.md

@@ -0,0 +1,27 @@
+<!--Lightweight issue template to facilitate decision making by using Decision Matrix -->
+
+## Problem to solve
+
+<!--Link to Description of feature (Documentation, Epic, Opportunity Canvas, etc.) -->
+
+## Decision Matrix
+
+<!-- Decision Matrix helps make a decision based on the acceptance criteria defined for the problem. Acceptance criteria should be put into left column, in the order of importance, with clear information if they are required (must-have) or not (nice-to-have). Options to consider should be scored in the right-side columns. To mark option as viable, it should fulfill all required criteria. -->
+
+| Acceptance criteria | Required | Option 1                           | Option 2                           |
+| ------------------- | -------- | ---------------------------------- | ---------------------------------- |
+| Criteria 1          | Yes/No   | :white_check_mark:/:no_entry_sign: | :white_check_mark:/:no_entry_sign: |
+| Criteria 2          | Yes/No   | :white_check_mark:/:no_entry_sign: | :white_check_mark:/:no_entry_sign: |
+| Criteria 3          | Yes/No   | :white_check_mark:/:no_entry_sign: | :white_check_mark:/:no_entry_sign: |
+| Criteria 4          | Yes/No   | :white_check_mark:/:no_entry_sign: | :white_check_mark:/:no_entry_sign: |
+| **Option Viable?**  | -        | Yes/No                             | Yes/No                             |
+
+## Decision due date
+
+<!--Defining due date for decision aligned with our Efficiency value. -->
+
+## Final decision
+
+<!--Filled after the due date and evaluating all options based on acceptance criteria.-->
+
+/label ~"group::" ~"section::" ~"Category:"

.gitlab/issue_templates/Default.md

@@ -0,0 +1,3 @@
+If you feel that your issue can be categorized as a reproducible bug or a
+feature proposal, please use one of the issue templates provided and include as
+much information as possible.

.gitlab/issue_templates/Deprecations.md

@@ -0,0 +1,125 @@
+<!-- Use this template as a starting point for deprecations. -->
+
+**A written process alone is unlikely to be sufficient to navigate through many
+complexities. Please use this template as guidance with steps to take when
+deprecating functionality, but not as an exhaustive list designed to generate
+positive outcomes every time. Deprecations are often nuanced in their impact and
+the approach needed may not be fully covered in this template.**
+
+---
+
+### Deprecation Summary
+
+_Add a brief description of the feature or functionality that is deprecated.
+Clearly state the potential impact of the deprecation to end users._
+
+#### Documentation
+
+- Deprecation notice: [add link](here)
+- Migration guidelines: [add link](here)
+- etc.
+
+#### Reasons
+
+\_Describe why deprecation of this feature is necessary
+
+- [add links to the documentation](here) - i.e. Decision-Matrix, etc.
+
+### Breaking Change?
+
+<!-- If the change includes removing functionality, which nearly all deprecations do, then it needs to be tracked as a breaking change. If user workflows rely on it to function, then removing it will break them. -->
+
+Does this deprecation contain a breaking change? `Yes / No`
+
+<!-- If yes:
+- Add the ~"breaking change" label to this issue.
+- Add instructions for how users can update their workflow.
+- After creating this issue, add an Internal Note in the comments below to document the pros and cons of this change and why we are choosing to make a breaking change. Answer the following:
+   - What migration paths are available?
+   - Describe tradeoffs between the migration paths taking into account customer, financial, technical or operational impact?
+   - Are there different migration path options for different users? (ex. available for ultimate users, but not free users?)
+   - Are there external requirements that we need to meet that restrict our available options?
+   - Consider the information you will also be adding in the "Affected Customers" section - this will impact how you plan for migration alternatives.
+ -->
+
+<!--
+/label ~"breaking change"
+-->
+
+### Affected Users
+
+Who is affected by this deprecation: GitLab.com users, Self-managed users, or
+Dedicated users? (choose all that apply)
+
+- [ ] GitLab.com
+- [ ] Self-managed
+- [ ] Dedicated
+
+### Deprecation Milestone
+
+This deprecation will be announced in milestone: `xx.xx` _If this deprecation
+has already been announced, include information about when the initial
+announcement went out and what follow-up announcements are scheduled._
+
+### Planned Removal Milestone
+
+The feature / functionality will be removed in milestone: `xx.xx`
+
+### Links
+
+<!--
+Add links to any relevant documentation or code that will provide additional details or clarity regarding the planned change.
+
+This issue is the main SSOT for the deprecations and removals process. Be sure to link all
+issues and MRs related to this deprecation/removal to this issue. This can include removal
+issues that were created ahead of time, and the MRs doing the actual deprecation/removal work.
+-->
+
+### Checklists
+
+#### Timeline
+
+#### Communication Plan
+
+- DRI Product Manager: `@PM`
+
+An internal slack post and a release post are not sufficient notification for
+our customers or internal stakeholders. Plan to communicate proactively and
+directly with affected customers and the internal stakeholders supporting them.
+
+Internal Communication Plan
+
+- [ ] Internal announcement plan (timeline for notifications, audience,
+      channels, etc)
+
+External Communication Plan
+
+- [ ] User announcement plan (timeline for notifications, audience, channels,
+      etc)
+  - [ ] Documentation has been updated to mark the feature as `deprecated`. _Add
+        link to the relevant merge request._
+- [ ] On the major milestone:
+  - [ ] The deprecated item has been removed. _Add link to the relevant merge
+        request._
+  - [ ] If the removal of the deprecated item is a
+        [breaking change](https://docs.gitlab.com/update/terminology/#breaking-change),
+        the merge request is labeled ~"breaking change".
+  - [ ] Document the migration plan for users, clearly outlining the actions
+        they need to take to mitigate the impact of the breaking change.
+    - [ ] [Add link](here)
+
+#### Labels
+
+<!-- Populate the Section, Group, and Category -->
+
+/label ~group: ~"Category:
+
+- [ ] This issue is labeled ~deprecation, and with the relevant `~group::`, and
+      `~Category:` labels.
+- [ ] This issue is labeled ~"breaking change" if the removal of the deprecated
+      item will be a
+      [breaking change](https://docs.gitlab.com/update/terminology/#breaking-change).
+
+<!-- Identifies that this Issue is related to deprecating a feature -->
+
+/label ~"deprecation"

.gitlab/issue_templates/Documentation.md

@@ -0,0 +1,44 @@
+<!--
+
+* Use this issue template for suggesting new docs or updates to existing docs.
+  Note: Doc work as part of feature development is covered in the Feature Request template.
+-->
+
+- [ ] Start this issue's title with `Docs:` or `Docs feedback:`.
+
+## Problem to solve
+
+<!--
+Include the following detail as necessary:
+
+* What feature(s) are affected?
+* What docs or doc section affected? Include links or paths.
+* Is there a problem with a specific document, or a feature/process that's not addressed sufficiently in docs?
+* Any other ideas or requests?
+-->
+
+## Further details
+
+<!--
+* Any concepts, procedures, reference info we could add to make it easier to successfully use this?
+* Include use cases, benefits, and/or goals for this work.
+* If adding content: What audience is it intended for? (What roles and scenarios?)
+-->
+
+## Proposal
+
+<!-- Further specifics for how can we solve the problem. -->
+
+## Who can address the issue
+
+<!-- What if any special expertise is required to resolve this issue? -->
+
+## Other links/references
+
+<!-- For example, related GitLab issues/MRs -->
+
+/label ~"documentation" /label ~"docs-only"
+
+/label ~"type::maintenance" ~"maintenance::refactor"
+
+/milestone %Backlog

.gitlab/issue_templates/Experiment Idea.md

@@ -0,0 +1,41 @@
+## Experiment summary
+
+We believe that... {describe your hypothesis in one sentence}
+
+To verify that, we will... {describe your test in one sentence}
+
+And we’ll measure the impact on... {metrics}
+
+## Hypothesis
+
+<!-- The hypothesis represents the high-level thought process in creating the experiment but does not need to be proven in one experiment. For example, you could have a hypothesis that “users would benefit from more easily being able to have a one-click-sandbox” and your first experiment could fail, that doesn’t void your hypothesis only indicates you may need to think of a new iterative experiment that would still align with your hypothesis. -->
+
+## Supporting data
+
+<!-- Why should we run this experiment? Why do you belive your Hypothesis to be true? -->
+
+## Expected outcome
+
+<!-- What is the expected outcome of this experiment, what metric are we trying to move? Are there any metrics we know we do not want to impact? -->
+
+## Experiment design & implementation
+
+<!-- What is the experiment we’re going to run? -->
+
+## Known assumptions
+
+<!-- This is an area to call out known assumptions in the experiment, this is especially helpful for any future colleagues that join the team so they understand other potential influences and how they were accounted for. This section is also helpful in framing possible scenarios and to keep the door open for the next steps. For example, we’re hoping our experiment will ... but we’re assuming .... This is a known assumption and depending on the results of the experiment could impact the direction we take on any future iterations. -->
+
+## Results, lessons learned, next steps
+
+<!-- What were the results of the experiment? Was the experiment a success or a failure? Based on the results should we remove the code or advocate that it become a permanent part? Are there future experiments to run based off these results (include a link to new issue)? For example, our trial experiment was successful we ... but saw .... Our next experiment (link) will focus on .... -->
+
+## Checklist
+
+- [ ] Fill in the experiment summary and write more about the details of the
+      experiment in the rest of the issue description. Some of these may be
+      filled in through time (the "Result, learnings, next steps" section for
+      example) but at least the experiment summary should be filled in right
+      from the start.
+
+/label ~"workflow::validation backlog" ~"experiment idea"

.gitlab/issue_templates/Experiment Implementation.md

@@ -0,0 +1,25 @@
+<!-- Title suggestion: Experiment Implementation: [description] -->
+
+# Experiment Summary
+
+<!-- Quick rundown of what is being done or a link to the Experiment epic -->
+
+# Design
+
+<!-- This should include the contexts that determine the reproducibility of an experiment. -->
+
+# Control vs Candidate Experience
+
+<!-- This should include a screenshot of the ground-truth vs experiment and any helpful context regarding expected outcomes -->
+
+| Control | Experiment |
+| ------- | ---------- |
+|         |            |
+
+# Tracking Details
+
+<!-- Record of what was tried/done when -->
+
+| activity | category | action | label |
+| -------- | -------- | ------ | ----- |
+|          |          |        |       |

.gitlab/issue_templates/Feature Proposal - basic.md

@@ -0,0 +1,10 @@
+<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
+
+### Proposal
+
+<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
+
+<!-- Consider adding related issues and epics to this issue. You can also reference the detailed Feature Proposal Template for additional details to consider adding to this issue.
+-->
+
+/label ~Category: /label ~"type::feature" ~"feature::addition" ~documentation

.gitlab/issue_templates/Feature Proposal - lean.md

@@ -0,0 +1,17 @@
+<!-- This issue template can be used as a great starting point for feature requests.
+
+The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed feature proposal. -->
+
+### Release notes
+
+<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places. -->
+
+### Problem to solve
+
+<!-- What is the user problem you are trying to solve with this issue? -->
+
+### Proposal
+
+<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
+
+/label ~"type::feature"

.gitlab/issue_templates/Feature proposal - detailed.md

@@ -0,0 +1,44 @@
+<!-- This issue template can be used as a great starting point for feature requests. The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook:  https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps validate the problem and start working on a solution. -->
+
+### Release notes
+
+<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places. -->
+
+### Problem to solve
+
+<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
+
+### User experience goal
+
+<!-- What is the single user experience workflow this problem addresses?
+For example, "The user should be able to <perform a specific task>"
+-->
+
+### Proposal
+
+<!-- How are we going to solve the problem? Try to include the user journey! -->
+
+### Further details
+
+<!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. -->
+
+### Documentation
+
+<!-- To be filled out later with links to Documentation Issues -->
+
+### Impact
+
+<!-- This section needs to be retained and filled in during the workflow planning phase of this feature proposal, if not earlier.
+
+What risks does this change pose to this project? What additional test coverage or changes to tests will be needed? Will it require extensive testing?
+
+Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
+* Unit test changes
+* Integration test changes
+* End-to-end test change
+
+ -->
+
+### Links / references
+
+/label ~"type::feature"

.gitlab/issue_templates/Implementation.md

@@ -0,0 +1,37 @@
+<!--
+Implementation issues are used break-up a large piece of work into small, discrete tasks that can
+move independently through the build workflow steps. They're typically used to populate a Feature
+Epic. Once created, an implementation issue is usually refined in order to populate and review the
+implementation plan and weight.
+-->
+
+## Relevant links
+
+<!--
+Information that the developer might need to refer to when implementing the issue.
+
+Basically a list of issues (bugs that are fixed, features implemented, etc. pp.)
+-->
+
+## Non-functional requirements
+
+<!--
+Add details for required items and delete others.
+-->
+
+- [ ] Documentation:
+
+## Verification steps
+
+<!--
+Add verification steps to help team members test the implementation. This is particularly useful
+during the ~"workflow::verification" step. You may not know exactly what the
+verification steps should be during issue refinement, so you can always come back later to add
+them.
+
+1. Check-out the corresponding branch
+1. ...
+1. Profit!
+-->
+
+/label ~"workflow::refinement" /milestone %Backlog

.gitlab/issue_templates/Refactoring.md

@@ -0,0 +1,25 @@
+## Summary
+
+<!--
+Please briefly describe what part of the code base needs to be refactored.
+-->
+
+## Improvements
+
+<!--
+Explain the benefits of refactoring this code.
+-->
+
+## Risks
+
+<!--
+Please list features that can break because of this refactoring and how you intend to solve that.
+-->
+
+## Involved components
+
+<!--
+List files or directories that will be changed by the refactoring.
+-->
+
+/label ~"type::maintenance"

CHANGELOG.md

@@ -0,0 +1,11 @@
+# Changelog
+
+Dokumentation der Änderungen pro Version:
+
+## [v1.0.0] – 2025-05-08
+
+- Erste stabile Version
+
+## [v0.1.0] – 2025-03-15
+
+- Erstes öffentliches Release

CITATION.md

@@ -0,0 +1,19 @@
+# Wie wird die Software zitiert?
+
+Nenne hier die bevorzugte Zitierweise für Publikationen oder DOI:
+
+```markdown
+Nachname, Vorname. (Jahr). Projektname (Version X.Y.Z). DOI oder URL.
+```
+
+```bibtex
+@software{bibtex-key,
+  author = {{}},
+  title = {Projektname},
+  url = {Projekthomepage},
+  version = {version},
+  date = {datum versions-release},
+}
+```
+
+- **Keine langen Beschreibungen**, nur den Zitierhinweis.

CONTRIBUTING.md

@@ -0,0 +1,19 @@
+# Wie beiträgt man zum Projekt?
+
+Anleitung zur Mitarbeit am Projekt.
+
+## Bugs melden & Vorschläge
+
+Wie meldet man Fehler oder schlägt Features vor?
+
+Vorbereitet ist der Gebrauch des GitLab-Issue-Trackers zusammen mit
+entsprechenden Templates, die Dinge erleichtern.
+
+## Code beisteuern
+
+Richtlinien für Codequalität und Beiträge:
+
+- Wie erstelle ich einen Pull Request?
+- Gibt es Stilrichtlinien (z.B. PEP8 für Python)?
+
+- **Nicht überkomplizieren**, sondern klaren Workflow beschreiben.

INSTALL.md

@@ -0,0 +1,18 @@
+---
+date: 2025-05-14 # when was this touched last?
+---
+
+# Installation
+
+Ausführliche Schritt-für-Schritt Anleitung zur Installation.
+
+## Voraussetzungen
+
+Hier alle Abhängigkeiten (z.B. Python-Version, Pakete, externe Tools) listen.
+
+## Schritte zur Installation
+
+Detaillierte Installationsanweisungen (Code-Blöcke, Terminal-Befehle).
+
+- **Nicht ausführlich Grundlagen erklären**, stattdessen verlinken auf externe
+  Ressourcen.

README.md

@@ -0,0 +1,161 @@
+---
+title: "<Projektname>"
+description: |
+  Kurze Beschreibung (2-3 Sätze), was die Software macht und welches wissenschaftliche Problem sie löst.
+lang: de
+date: 2025-05-14
+authors:
+  - name: Your Name
+    affiliation:
+      - name: Your Institution
+        url: Institutions homepage
+    email: your@email.here
+    orcid: 0000-0000-0000-0000
+    roles: # CRediT-Roles - see https://credit.niso.org/
+      - Conceptualization
+      - Supervision
+      - Validation
+  # ... weitere Autor*innen
+---
+
+Auf Wunsch Beschreibung noch einmal wiederholen
+
+## Über dieses Repository
+
+### Ziel / Zweck
+
+Kurz das Ziel oder den Bedarf der Software erläutern.  
+(Beispiel: „Diese Software analysiert historische Textdaten, um Netzwerke
+sozialer Interaktionen zu rekonstruieren.“)
+
+Ist die Software noch in Entwicklung? Abgeschlossen? Abgebrochen?
+
+### Installation
+
+Kurz und präzise beschreiben, wie die Software installiert wird (max. 3-5
+Schritte).
+
+- Verweise ggf. auf ausführliche [INSTALL.md](INSTALL.md)
+
+> [!warning]
+>
+> **Keine ausführliche Erklärung** von Standard-Tools (z.B. Python
+> installieren), sondern verlinken auf offizielle Seiten
+
+### Nutzung
+
+Minimalbeispiel, wie die Software genutzt wird (kurzer Codeblock oder
+Kommandozeilenaufruf mit typischem Input und Output).
+
+> [!warning]
+>
+> **Nicht zu komplexe Beispiele**, dafür ggf. auf ausführliches Tutorial (Datei
+> [USAGE.md](USAGE.md) oder Verzeichnis [examples/](examples/)) verweisen
+
+### Bekannte Einschränkungen
+
+Kurz bekannte Probleme und Limitationen nennen, um Missverständnisse zu
+vermeiden.
+
+> [!warning]
+>
+> **Keine** ausschweifenden technischen Details, sondern praktische Hinweise.
+
+### Struktur
+
+```plain
+Übersicht der Struktur z.b. generiert mittels
+`tree -L2` oder `tree -L2 -d`
+und anschließend überarbeitet
+```
+
+- Kurze Beschreibung - entweder direkt im Tree oder hier in Prosa
+- Ziel: Überblick über "Wo finde ich was". Wo ist Doku? Wo ist Code? Wo ist ...?
+
+> [!warning]
+>
+> **Keine Details**, die über 1 Satz pro Element hinaus gehen. Bei detailliertem
+> Bedarf `README.md` im jeweiligen Verzeichnis.
+
+## Meta-Informationen
+
+### Verantwortlichkeiten
+
+- Wer ist letztendlich verantwortlich für den Inhalt?
+- Wer genehmigt/weist Inhalte ab?
+
+### Wissenschaftlicher Hintergrund
+
+Kurze Erklärung der wissenschaftlichen Grundlage (Methode, theoretischer Ansatz)
+und Referenzen auf Publikationen oder Quellen.
+
+> [!warning]
+>
+> **Keine ausführliche Theorie**, diese gehört in Paper oder eigene Datei
+> ([BACKGROUND.md](BACKGROUND.md))
+
+### Lizenz & Zitation
+
+Kurz auf Lizenz verweisen (z.B. „siehe LICENSE“) und erklären, wie das Projekt
+zu zitieren ist (z.B. DOI oder Verweis auf [CITATION.md](CITATION.md)).
+
+---
+
+## Empfohlene Dokumentations-Dateien
+
+| **Dokuelement**                    | **Inhalt/Purpose**                                                                                                       | **Format/Ort**                                                                         | **Umfang**                            |
+| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | ------------------------------------- |
+| **README (Hauptdoku)**             | Zweck der Software; Kurzbeschreibung; Installationsanleitung; einfaches Nutzungsbeispiel; Lizenz- und Kontaktinfo        | Markdown im Root des Repos (statisch versioniert)                                      | 1–2 Seiten                            |
+| **Eingabe/Ausgabe-Guide**          | Beschreibung der erwarteten Inputs (Datenformat, Parameter) und generierten Outputs (Dateien, Berichte) inkl. Beispielen | Teil der README oder separate Datei (z.B. USAGE.md)                                    | 1 Seite (mit Beispielen)              |
+| **Wissenschaftlicher Hintergrund** | Erläuterung der Methode, Theorie, Algorithmen; Verweise auf Literatur                                                    | README-Abschnitt "Hintergrund" oder separate Doku (BACKGROUND.md)                      | 0.5–1 Seite (plus Referenzen)         |
+| **Bekannte Limitationen**          | Auflistung von Einschränkungen, Annahmen, bekannten Problemen; ggf. Workarounds                                          | README-Abschnitt "Limitations" oder FAQ.md                                             | 0.5 Seite                             |
+| **Beispiel-Workflow (Tutorial)**   | Schritt-für-Schritt Anleitung mit einem realistischen Anwendungsfall (ggf. mit Code und Screenshot)                      | Jupyter Notebook (`.ipynb`) im Repo `examples/` Ordner oder Markdown in docs/          | 1–3 Seiten / entsprechend Zellen      |
+| **API-Referenz**                   | Technische Dokumentation von Funktionen/Klassen für Entwickler\*innen                                                    | Automatisch generiert aus Docstrings (z.B. Sphinx in `docs/` Ordner, HTML/PDF Ausgabe) | Je nach Codegröße (ggf. umfangreich)  |
+| **CONTRIBUTING**                   | Anleitung für Beitragswillige: Code Style, Workflow, Tests, Kontakt                                                      | CONTRIBUTING.md im Repo                                                                | 0.5–1 Seite                           |
+| **LICENSE** / **CITATION**         | Rechtliche Infos (Lizenztext); Zitationsleitfaden (Bevorzugte Zitierweise, DOI)                                          | Jeweils eigene Datei im Repo (Plain Text/Markdown)                                     | Kurz (Standardtext bzw. Referenz)     |
+| **Release-Information**            | Versionshinweise, Änderungsprotokoll (Changelog)                                                                         | CHANGELOG.md oder Releases auf GitHub                                                  | fortlaufend pro Version (Stichpunkte) |
+
+## Checklist
+
+Es ist eine gute Idee die sich ändernden Punkte in ein Release-Template zu
+kopieren.
+
+- [ ] **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.

USAGE.md

@@ -0,0 +1,19 @@
+---
+title: "Nutzung der Software"
+date: 2025-05-14 # zuletzt angepasst
+version: v1.0 # Auf welche Version bezieht sich dies?
+---
+
+Ausführliche Beschreibung typischer Workflows oder Beispielanwendungen.
+
+## Beispiele
+
+Detaillierte Schritt-für-Schritt-Anleitungen mit Inputs und Outputs.  
+Evtl. Screenshots oder Abbildungen zur besseren Verständlichkeit.
+
+- **Keine zu detaillierten technischen Details**, Fokus auf realistische
+  Anwendungsfälle.
+
+## FAQs (optional)
+
+Häufig auftretende Fragen zur Nutzung kurz und prägnant beantworten.