Zum Hauptinhalt springen

group_add Beitragen & Lizenzfeedback

Open Source Maintained Security

Diese Seite beschreibt, wie Sie aktiv zum BMDS Architekturmanagement-Portal beitragen können – sei es durch Kommentare, inhaltliche Korrekturen oder neue Inhalte. Außerdem finden Sie hier die geltenden Lizenzbestimmungen und unsere Netiquette.

article Lizenzfeedback

Dieses Projekt steht unter einem Dual-Lizenz-Modell:

GegenstandLizenzErlaubt
Inhalte (Texte, Dokumentation, Diagramme)CC BY 4.0Teilen, Bearbeiten, auch kommerziell – bei Namensnennung.
Quellcode (Konfiguration, Skripte, Komponenten)Apache License 2.0Freie Nutzung, Verbreitung und Modifikation – bei Erhalt des Lizenzhinweises.

Warum dieses Modell?

  • CC BY 4.0 für Inhalte stellt sicher, dass Verwaltungen, Dienstleister und die Öffentlichkeit die Dokumentation frei nachnutzen können – ein Kernprinzip von Open Government Data.
  • Apache 2.0 für den Code bietet Patentschutz, klare Haftungsausschlüsse und ist mit nahezu allen Open-Source-Lizenzen kompatibel.
  • Beide Lizenzen sind vom IT-Planungsrat und der Open Source Business Alliance für den öffentlichen Sektor empfohlen.
Hinweis

Mit jedem Beitrag zu diesem Projekt erklären Sie sich damit einverstanden, dass Ihre Beiträge unter den oben genannten Lizenzen veröffentlicht werden.

how_to_reg Voraussetzung: Registrierung auf OpenCodefeedback

Alle Beiträge laufen über die GitLab-Instanz OpenCode – die Open-Source-Plattform der öffentlichen Verwaltung.

So registrieren Sie sich:

  1. Öffnen Sie gitlab.opencode.de in Ihrem Browser.
  2. Klicken Sie auf „Registrieren" (oben rechts).
  3. Verwenden Sie Ihre dienstliche E-Mail-Adresse oder einen bestehenden Account (GitHub, ELSTER-ID).
  4. Bestätigen Sie Ihre E-Mail-Adresse.
  5. Navigieren Sie zum Projekt: egovlab/refa-test

Nach der Registrierung können Sie Issues anlegen, kommentieren und Änderungen über die Web IDE vorschlagen.

comment Feedback geben: Kommentare als GitLab Issuesfeedback

Auf jeder Seite dieses Portals gibt es zwei Möglichkeiten, Feedback zu geben:

Kommentar unter jedem Kapitelfeedback

Unter jedem Kapitel (Überschrift) finden Sie einen Kommentar-Button. Dieser legt automatisch ein GitLab Issue mit dem Kontext (Seitentitel, Kapitel, URL) an. So können Sie gezielt auf einzelne Abschnitte reagieren – z.B. inhaltliche Fehler melden, Ergänzungen vorschlagen oder Verständnisfragen stellen.

Kommentar am Seitenendefeedback

Am Ende jeder Seite finden Sie zusätzlich:

  • „Feedback geben" – legt ein allgemeines Issue zur gesamten Seite an.
  • „Seite bearbeiten" – öffnet die Seite direkt in der GitLab Web IDE, sodass Sie Änderungen vorschlagen können (Merge Request).

Alle Issues einsehenfeedback

Sämtliche Kommentare und Feedback-Issues sind öffentlich einsehbar und filterbar:

👉 Alle Issues anzeigen

Sie können Issues filtern nach:

  • Status: Offen / Geschlossen
  • Label: z.B. feedback, inhalt, bug, frage
  • Erstellt von: eigene Issues
  • Seite / Bereich: über Labels oder Titelpräfix

edit Inhalte bearbeitenfeedback

Schnelle Korrektur (Web IDE)feedback

  1. Klicken Sie am Seitenende auf „Seite bearbeiten".
  2. GitLab öffnet die Datei in der Web IDE.
  3. Nehmen Sie Ihre Änderung vor (Markdown-Syntax).
  4. Klicken Sie auf „Commit" → wählen Sie „Neuen Branch erstellen und Merge Request starten".
  5. Beschreiben Sie kurz Ihre Änderung und senden Sie den Merge Request ab.

Web IDE

Umfangreiche Beiträge (lokal)feedback

# Repository klonen
git clone https://gitlab.opencode.de/egovlab/refa-test.git
cd refa-test

# Abhängigkeiten installieren
npm install

# Lokalen Entwicklungsserver starten
npm run dev

# Neuen Branch erstellen
git checkout -b feature/mein-beitrag

# Änderungen committen und pushen
git add .
git commit -m "docs: Beschreibung der Änderung"
git push origin feature/mein-beitrag

Anschließend erstellen Sie auf GitLab einen Merge Request gegen den master-Branch.

Commit-Konventionenfeedback

Verwenden Sie Conventional Commits:

PräfixVerwendung
docs:Inhaltliche Änderungen an Dokumentation
fix:Korrekturen (Tippfehler, fehlerhafte Links)
feat:Neue Seiten oder Abschnitte
style:Formatierung, CSS-Änderungen
chore:Build-Skripte, Konfiguration

verified Review-Prozessfeedback

Alle Beiträge durchlaufen einen Review-Prozess:

  1. Automatische Prüfung – Build-Pipeline prüft auf fehlerhafte Links, Markdown-Fehler und Barrierefreiheit.
  2. Inhaltliche Review – Ein:e Maintainer:in prüft den Beitrag auf fachliche Korrektheit und Konsistenz.
  3. Merge – Nach Freigabe wird der Beitrag in den master-Branch übernommen und automatisch veröffentlicht.

Typische Review-Dauer: 3–5 Werktage.

handshake Netiquettefeedback

Für eine respektvolle und produktive Zusammenarbeit gelten die folgenden Regeln für alle Interaktionen in Issues, Merge Requests und Kommentaren:

Grundsätzefeedback

  1. Respektvoller Umgang – Wir kommunizieren sachlich, wertschätzend und konstruktiv. Persönliche Angriffe, Beleidigungen oder Diskriminierung jeglicher Art sind nicht akzeptabel.

  2. Sachlichkeit – Beiträge beziehen sich auf den fachlichen Inhalt. Meinungsverschiedenheiten werden durch Argumente und Quellen ausgetragen, nicht durch Lautstärke.

  3. Konstruktives Feedback – Kritik ist erwünscht, wenn sie konkret, nachvollziehbar und lösungsorientiert formuliert ist. Statt „Das ist falsch" schreiben Sie besser: „In §X VwVfG steht Y, hier sollte Z angepasst werden."

  4. Klarheit – Formulieren Sie präzise. Geben Sie Kontext an (welche Seite, welcher Abschnitt, warum). Nutzen Sie Quellenangaben, wenn Sie auf externe Dokumente verweisen.

  5. Datenschutz – Veröffentlichen Sie keine personenbezogenen Daten, internen Dienstgeheimnisse oder eingestufte Informationen in Issues oder Kommentaren.

  6. Sprache – Die Dokumentationssprache ist Deutsch. Issues und Kommentare können auf Deutsch oder Englisch verfasst werden.

  7. Keine Werbung – Beiträge dienen der Verbesserung der Dokumentation, nicht der Produktwerbung oder Eigenvermarktung.

Konsequenzen bei Verstößenfeedback

Bei Verstößen gegen die Netiquette behalten sich die Maintainer:innen vor:

  • Kommentare zu bearbeiten oder zu entfernen.
  • Wiederholte Verstöße durch temporäre oder dauerhafte Sperrung zu sanktionieren.
  • Bei schwerwiegenden Verstößen die zuständige Stelle zu informieren.

Ansprechpersonenfeedback

Bei Fragen zur Netiquette oder bei gemeldeten Verstößen wenden Sie sich an das Projektteam über die GitLab-Projektseite.


Kurzfassung: So tragen Sie bei
  1. Registrieren auf OpenCode
  2. Issue anlegen oder Kommentar schreiben (unter jedem Kapitel möglich)
  3. Oder: Seite direkt über die Web IDE bearbeiten
  4. Netiquette beachten – sachlich, konstruktiv, respektvoll