Skriva en bra patch

Skriv separata ändringar

Det är irriterande när man får en enorm patch som sägs fixa 11 udda problem, men diskussioner och åsikter inte stämmer överens med 10 av dem eller 9 av dem redan har fixats på ett annat sätt. Då måste den person som sammanfogar denna ändring extrahera den enda intressanta patchen från någonstans i den enorma högen av källor, och det skapar en hel del extra arbete.

Helst bör varje korrigering som åtgärdar ett problem finnas i en egen patch/commit med en egen beskrivning/commit-meddelande som anger exakt vad som korrigeras, så att alla ändringar kan tillämpas selektivt av underhållaren eller andra berörda parter.

Dessutom möjliggör separata ändringar en mycket bättre uppdelning för att spåra problem och regressioner i framtiden.

Dokumentation

Dokumentation kan vara ett tråkigt arbete, men det är nödvändigt att någon gör det. Det underlättar mycket om du skickar in dokumentationen tillsammans med kodändringarna. Kom ihåg att dokumentera metoder, komplexa kodblock eller funktioner som är synliga för användaren.

Se även

Bidra till Weblate-dokumentationen

Testfall

Testerna gör det möjligt för oss att snabbt verifiera att funktionerna fungerar som de ska. För att upprätthålla denna situation och förbättra den måste alla nya funktioner som läggs till testas i testpaketet. Varje funktion som läggs till bör få minst ett giltigt testfall som verifierar att den fungerar enligt dokumentationen.

Se även

Weblate testsuite och kontinuerlig integration

Arkiveringssmeddelande

Git-commits ska följa specifikationen Conventional Commits.

Typskontroll

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.

Kodningsstandard och linting av koden

Koden ska följa PEP 8 kodningsriktlinjer och ska formateras med hjälp av ruff kodformaterare.

För att kontrollera kodkvaliteten kan du använda ruff, vars konfiguration lagras i pyproject.toml.

The easiest approach to enforce all this is to install prek. This is a third-party reimplementation of the pre-commit tool used by Weblate. It is included in the development dependencies declared in pyproject.toml, so installing those dependencies makes prek available.

To check all files manually, run:

uv run prek run --all-files

If you prefer the original pre-commit client, it uses the same configuration from .pre-commit-config.yaml.

Säker kodning

All kod för Weblate bör skrivas med Security by Design Principles i åtanke.

Riktlinjer för AI

När du bidrar med innehåll till projektet ger du oss tillstånd att använda det som det är, och du måste se till att du har rätt att distribuera det till oss. Genom att skicka in en ändring till oss samtycker du till att ändringarna kan och bör antas av projektet och distribueras vidare under projektlicensen. Författare bör vara uttryckligen medvetna om att det är deras ansvar att se till att ingen olicensierad kod skickas in till projektet.

Detta är oberoende av om AI används eller inte.

När du bidrar med en pull-förfrågan bör du naturligtvis alltid se till att förslaget är av god kvalitet och att det bästa möjliga arbete har lagts ner i enlighet med våra riktlinjer. En grundläggande tumregel är att om någon kan se att bidraget har skapats med hjälp av AI, har du mer arbete att göra.

Vi kan acceptera kod som skrivits med hjälp av AI i projektet, men koden måste fortfarande följa kodningsstandarder, vara tydligt skriven, dokumenterad, innehålla testfall och uppfylla alla våra normala krav.