Bijdragen aan Agovena

Bedankt dat je aan Agovena wilt bijdragen. Je kunt helpen met code, documentatie, tests, design, vertalingen, bugreports of ideeën voor het project.

1. Kies een bijdrage

Begin met de kleinste nuttige verbetering die je kunt maken:

• Meld een reproduceerbare bug of onduidelijkheid in de documentatie.
• Verbeter een bestaande functie in plaats van direct een grote redesign te starten.
• Voeg tests toe of corrigeer tests voor gedrag dat niet mag terugvallen.
• Verbeter de Engelse of Nederlandse documentatie en interfacecopy.
• Bouw een Module, Extension of Theme wanneer de wijziging niet in de gedeelde Core hoort.

Meld beveiligingsproblemen niet in een openbaar issue. Volg het securitybeleid.

2. Controleer bestaand werk

Zoek eerst in de open issues en pull requests voordat je begint. Open voor een grotere wijziging eerst een issue en leg uit:

1. Welk probleem wil je oplossen?
2. Wie heeft daar last van?
3. Welk resultaat verwacht je?
4. Hoe houd je de wijziging klein en onderhoudbaar?

Zo voorkom je dubbel werk en kunnen maintainers de richting bespreken voordat er code wordt geschreven.

3. Maak je branch

Fork de repository waarin je wilt wijzigen, clone je fork en maak een duidelijke branch:

git clone https://github.com/<jouw-account>/Agovena.git
cd Agovena
git checkout -b fix/beschrijf-de-wijziging

Gebruik voor iedere bijdrage een aparte branch. Houd commits gericht en gebruik een betekenisvolle Conventional Commit, bijvoorbeeld fix: voorkom dubbele betalingsregistratie of docs: verduidelijk installatieroutes.

4. Richt het project in

Installeer de dependencies en volg de lokale installatiehandleiding met een aparte ontwikkel- of testdatabase:

composer install
npm ci
cp .env.example .env
php artisan key:generate
php artisan migrate
npm run build

De meeste wijzigingen horen in de hoofdrepository Agovena. Werk in de optional-packages-repository wanneer je een first-party Module of Extension wijzigt. Gebruik voor een checkout naast elkaar deze instelling in Core:

AGOVENA_OPTIONAL_PACKAGES_PATH=../optional-packages

Gebruik een Theme voor presentatiewijzigingen. Verplaats provider-specifiek gedrag of optionele commercefuncties niet naar Core alleen omdat dat sneller lijkt.

5. Bouw en test de wijziging

Houd de wijziging bij het probleem uit het issue of de pull request. Voeg een regressietest toe wanneer gedrag verandert. Controleer waar relevant succes, validatiefouten, rechten, lege toestanden en foutafhandeling.

Draai eerst de kleinste relevante test en daarna de toepasselijke projectcontroles:

php artisan test tests/Feature/YourTest.php
composer test
composer analyse
composer lint
npm run build

Test bij browserwijzigingen ook desktop- en mobile-layouts, toetsenbordfocus, beide kleurmodi, Engelse en Nederlandse copy en de relevante Playwright-suite. Gebruik nooit echte klantgegevens, productiedatabases, providercredentials of tokens voor lokale tests.

6. Open een pull request

Controleer vóór je de pull request opent:

• Lees de volledige diff opnieuw en voer git diff --check uit.
• Leg uit wat er is gewijzigd, waarom dat nodig was en hoe je het hebt getest.
• Vermeld beperkingen, overgeslagen controles en providergedrag dat niet live is getest.
• Werk relevante documentatie bij wanneer gebruikers of operators het gedrag merken.
• Verwijder debug-output, tijdelijke bestanden, secrets en claims over onaf werk.

Open de pull request tegen de juiste repository en houd deze gericht. Pas de implementatie aan wanneer review daar aanleiding toe geeft. Lees ook het bijdragebeleid voor de projectregels en de Code of Conduct voor de communityverwachtingen.