Lizenz und Urheberrecht¶
When contributing project code, you agree to put your changes and new code under the repository license, GPL-3.0-or-later, unless stated and agreed otherwise. New source files should follow the existing copyright and SPDX license header style.
Use a different license only when there is a deliberate reason, such as files shared with repositories using more permissive licenses.
Siehe auch
Weblate-Lizenz erklärt die Lizenzierung genauer.
Einen guten Patch schreiben¶
Separate Änderungen schreiben¶
Es ist ärgerlich, wenn man einen großen Patch erhält, der angeblich 11 Probleme behebt, aber die Diskussionen und Meinungen stimmen mit 10 davon nicht überein oder 9 davon wurden bereits anders behoben. Dann muss die Person, die diese Änderung zusammenführt, den einzigen interessanten Patch irgendwo aus dem riesigen Haufen von Quellen herausziehen, und das verursacht eine Menge zusätzliche Arbeit.
Vorzugsweise sollte jede Korrektur, die ein Problem behebt, in einem eigenen Patch/Commit mit einer eigenen Beschreibung/Commit-Nachricht sein, die genau angibt, was korrigiert wird, so dass alle Änderungen vom Betreuer oder anderen interessierten Parteien selektiv angewendet werden können.
Außerdem lassen sich durch getrennte Änderungen Probleme und Regressionen in Zukunft viel besser verfolgen.
Dokumentation¶
Dokumentation kann eine mühsame Aufgabe sein, aber es ist notwendig, dass jemand sie erledigt. Es macht die Sache viel einfacher, wenn Sie die Dokumentation zusammen mit den Codeänderungen einreichen. Bitte denken Sie daran, Methoden, komplexe Codeblöcke oder für den Benutzer sichtbare Funktionen zu dokumentieren.
Siehe auch
Testfälle¶
Die Tests ermöglichen es uns, schnell zu überprüfen, ob die Funktionen wie vorgesehen funktionieren. Um dies aufrechtzuerhalten und zu verbessern, müssen alle neu hinzugefügten Funktionen in der Testsuite getestet werden. Für jede hinzugefügte Funktion sollte mindestens ein gültiger Testfall erstellt werden, der die dokumentierte Funktion überprüft.
Commit-Nachrichten¶
Git-Commits sollten der Spezifikation Conventional Commits folgen.
Typprüfung¶
Any new code should utilize PEP 484 type hints. We are using mypy to check them because it has a Django plugin that makes type checking of Django apps practical.
New and changed code should not introduce new mypy failures where current Django typing support makes that practical. The code base is not yet completely covered by type annotations, and some Django constructs are difficult to annotate precisely. CI therefore enforces mypy only for selected modules and reports other findings separately.
Codierungsstandard und Codeanalyse¶
Der Code sollte den PEP 8-Programmierrichtlinien entsprechen und mit dem Code-Formatierer ruff formatiert werden.
Um die Codequalität zu überprüfen, kann ruff verwendet werden, dessen Konfiguration in pyproject.toml gespeichert ist.
Der einfachste Weg, dies alles zu erzwingen, ist die Installation von prek. Dies ist eine Drittanbieter-Reimplementierung des von Weblate verwendeten pre-commit-Tools. Es ist in den in pyproject.toml deklarierten Entwicklungsabhängigkeiten enthalten, sodass prek durch die Installation dieser Abhängigkeiten verfügbar wird.
Um alle Dateien manuell zu überprüfen, folgendes ausführen:
uv run prek run --all-files
Wenn Sie den ursprünglichen pre-commit-Client bevorzugen, verwendet dieser dieselbe Konfiguration aus .pre-commit-config.yaml.
Sicheres Programmieren¶
Jeder Code für Weblate sollte unter Berücksichtigung von Security by Design Principles geschrieben werden.
KI-Richtlinien¶
Wenn Sie Inhalte zum Projekt beitragen, erteilen Sie uns die Erlaubnis, diese unverändert zu verwenden, und Sie müssen sicherstellen, dass Sie sie an uns weitergeben dürfen. Indem Sie uns eine Änderung übermitteln, stimmen Sie zu, dass die Änderungen vom Projekt übernommen und unter der Projektlizenz weiterverbreitet werden können. Die Autoren sollten sich ausdrücklich darüber im Klaren sein, dass sie dafür verantwortlich sind, dass kein unlizenzierter Code an das Projekt übermittelt wird.
Dies ist unabhängig davon, ob KI eingesetzt wird oder nicht.
Wenn Sie einen Pull Request einreichen, sollten Sie natürlich immer darauf achten, dass der Vorschlag qualitativ hochwertig ist und unseren Richtlinien entspricht. Als Faustregel gilt: Wenn jemand erkennen kann, dass der Beitrag mithilfe von KI erstellt wurde, haben Sie mehr Arbeit zu erledigen.
Wir können mithilfe von KI geschriebenen Code in das Projekt aufnehmen, aber der Code muss weiterhin den Codierungsstandards entsprechen, klar geschrieben und dokumentiert sein, Testfälle enthalten und alle unsere normalen Anforderungen erfüllen.