80 lines
3.7 KiB
Markdown
80 lines
3.7 KiB
Markdown
# Zu Gardomatic beitragen
|
|
|
|
Vielen Dank für dein Interesse an Gardomatic. Beiträge sollen klein,
|
|
nachvollziehbar und mit der bestehenden Architektur vereinbar sein.
|
|
|
|
## Vor dem ersten Beitrag
|
|
|
|
1. Lies die Projektbeschreibung und den Entwicklungsablauf in der
|
|
[`README.md`](README.md).
|
|
2. Beachte die verbindlichen technischen Regeln in [`AGENTS.md`](AGENTS.md).
|
|
3. Lies die [`Contributor License Agreement`](CLA.md). Sie ist eine rechtlich
|
|
bindende Vereinbarung.
|
|
|
|
Mit der CLA behältst du das Copyright an deinem Beitrag. Du erlaubst Alexander
|
|
Klein zugleich, den Beitrag innerhalb von Gardomatic unter der öffentlichen
|
|
PolyForm-Lizenz sowie unter separaten kommerziellen oder proprietären Lizenzen zu
|
|
verwenden. Das ermöglicht das in diesem Projekt vorgesehene Dual-Licensing-Modell.
|
|
|
|
### CLA annehmen
|
|
|
|
Einzelpersonen nehmen Version 1.0 der CLA an, indem sie einen Pull Request mit der
|
|
unveränderten CLA-Erklärung aus der Pull-Request-Vorlage einreichen und die
|
|
zugehörige Checkbox selbst markieren. Die Annahme gilt auch für spätere Beiträge
|
|
unter derselben CLA-Version.
|
|
|
|
Der Workflow `.github/workflows/cla.yml` prüft diese Erklärung bei jedem Pull
|
|
Request. Ein fehlgeschlagener CLA-Check darf nicht umgangen oder administrativ als
|
|
Ersatz für die Zustimmung der beitragenden Person bestätigt werden.
|
|
|
|
Beiträge im Namen eines Unternehmens oder einer anderen Organisation müssen vorab
|
|
mit `alex@kleiax.de` abgestimmt werden. Dasselbe gilt, wenn dein Arbeitgeber Rechte
|
|
an deinem Beitrag besitzen könnte. Eine Projektperson darf die CLA-Erklärung nicht
|
|
stellvertretend für Beitragende markieren.
|
|
|
|
## Entwicklungsablauf
|
|
|
|
1. Erstelle einen fokussierten Branch und beschreibe das zu lösende Problem.
|
|
2. Suche vor der Implementierung nach vorhandenen Helfern und ähnlichen Abläufen.
|
|
3. Halte die Schichtengrenzen zwischen API, Storage, Client und Web ein.
|
|
4. Ergänze Tests für neues oder korrigiertes Verhalten, soweit technisch möglich.
|
|
5. Formatiere geänderten Go-Code mit `gofmt`.
|
|
6. Führe zunächst die betroffenen Tests und anschließend `go test ./...` aus.
|
|
7. Führe bei größeren Änderungen zusätzlich `make audit` aus.
|
|
8. Erläutere im Pull Request Verhalten, Motivation, Tests und mögliche Risiken.
|
|
|
|
Für Datenbankänderungen ist ein neues Up-/Down-Migrationspaar erforderlich.
|
|
Bereits veröffentlichte Migrationen dürfen nicht nachträglich verändert werden.
|
|
|
|
## Pull Requests
|
|
|
|
Ein Pull Request sollte:
|
|
|
|
- genau ein zusammenhängendes Problem lösen,
|
|
- keine unbeabsichtigten oder fachfremden Änderungen enthalten,
|
|
- vorhandene Tests nicht abschwächen,
|
|
- geändertes Nutzerverhalten und Konfiguration dokumentieren,
|
|
- alle verwendeten Quellen und Fremdmaterialien mit ihrer Lizenz offenlegen und
|
|
- die CLA-Erklärung enthalten.
|
|
|
|
Ein Beitrag kann abgelehnt oder bis zur Klärung zurückgestellt werden. Das gilt
|
|
insbesondere bei fehlender CLA-Annahme, unklaren Rechten, Sicherheitsproblemen,
|
|
fehlenden Tests oder Änderungen außerhalb des vereinbarten Umfangs.
|
|
|
|
## Fremdmaterial und KI-gestützte Beiträge
|
|
|
|
Reiche nur Material ein, an dem du die erforderlichen Rechte besitzt. Kopiere
|
|
keinen Code, keine Texte, Bilder oder anderen Inhalte aus inkompatibel lizenzierten
|
|
Quellen. Kennzeichne Fremdmaterial und nenne Quelle sowie Lizenz.
|
|
|
|
Für KI-gestützte Beiträge bleibst du selbst verantwortlich. Prüfe den erzeugten
|
|
Inhalt auf Korrektheit, Sicherheit, Herkunft und mögliche Lizenzkonflikte, bevor du
|
|
ihn einreichst.
|
|
|
|
## Sicherheitsprobleme
|
|
|
|
Noch nicht veröffentlichte Sicherheitslücken sollten nicht als öffentlicher Issue
|
|
oder Pull Request eingereicht werden. Melde sie zunächst vertraulich an
|
|
`alex@kleiax.de` und füge keine echten Zugangsdaten oder personenbezogenen Daten
|
|
bei.
|