Contribute to Agovena

Thanks for wanting to contribute to Agovena. You can help with code, documentation, tests, design, translations, issue reports, or ideas for the project.

1. Choose a contribution

Start with the smallest useful improvement you can make:

• Report a reproducible bug or a confusing part of the documentation.
• Improve an existing feature instead of starting a large redesign.
• Add or correct tests for a behavior that should not regress.
• Improve the English or Dutch documentation and interface copy.
• Build a Module, Extension, or Theme when the change belongs outside the shared Core.

For security issues, do not open a public issue. Follow the security policy.

2. Check existing work

Search the open issues and pull requests before starting. For a larger change, open an issue first and explain:

1. What problem are you trying to solve?
2. Who is affected?
3. What result would you expect?
4. How could the change stay small and maintainable?

This avoids duplicate work and gives maintainers a chance to discuss the direction before code is written.

3. Create your branch

Fork the repository you want to change, clone your fork, and create a descriptive branch:

git clone https://github.com/<your-account>/Agovena.git
cd Agovena
git checkout -b fix/describe-the-change

Use a separate branch for each contribution. Keep commits focused and use a meaningful Conventional Commit, for example fix: prevent duplicate payment recording or docs: clarify installation paths.

4. Set up the project

Install the dependencies and follow the local installation guide with a disposable development database:

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

Most changes belong in the main Agovena repository. If your change is a first-party Module or Extension, work in the optional-packages repository instead. For a side-by-side checkout, point Core to the package repository with:

AGOVENA_OPTIONAL_PACKAGES_PATH=../optional-packages

Use a Theme for presentation changes. Do not move provider-specific behavior or optional commerce features into Core just because it is quicker there.

5. Make and test the change

Keep the change focused on the problem described in the issue or pull request. Add a regression test when behavior changes. Check success, validation errors, permissions, empty states, and failure handling where they apply.

Run the narrowest useful test first, then the relevant project checks:

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

For browser-facing changes, also test desktop and mobile layouts, keyboard focus, both color modes, English and Dutch copy, and the relevant Playwright suite. Never use real customer data, production databases, provider credentials, or tokens for local testing.

6. Open a pull request

Before opening the pull request:

• Re-read the complete diff and run git diff --check.
• Explain what changed, why it was needed, and how you tested it.
• Mention limitations, skipped checks, or provider behavior that was not live-verified.
• Update relevant documentation when users or operators will notice the change.
• Remove debug output, temporary files, secrets, and unfinished claims.

Open the pull request against the correct repository and keep it focused. Be ready to adjust the implementation after review. See the repository contribution policy for the project rules and Code of Conduct for community expectations.