Spaces:
Running
Running
| <!-- translation: machine + human review pending --> | |
| <!-- canonical: CONTRIBUTING.md (FR) --> | |
| # Contributing to Picarones | |
| > 🇫🇷 [Version française](CONTRIBUTING.md) | |
| Thanks for considering a contribution! Picarones is an open-source | |
| project (Apache-2.0) that benefits from contributions across the | |
| spectrum: code, documentation, translations, case studies, | |
| accessibility audits. | |
| ## Pre-requisites | |
| - Python 3.11 or 3.12 (3.13 informational). | |
| - Git, GitHub account. | |
| - A working Picarones dev install: | |
| ```bash | |
| git clone https://github.com/maribakulj/Picarones.git | |
| cd Picarones | |
| pip install -e ".[dev,web]" | |
| pre-commit install | |
| ``` | |
| ## Workflow | |
| 1. **Fork** the repo on GitHub. | |
| 2. **Create a feature branch** from `main`: | |
| ```bash | |
| git checkout -b feature/your-feature | |
| ``` | |
| 3. **Make your change**, write tests, run them locally: | |
| ```bash | |
| pytest tests/ -q --tb=short | |
| ruff check picarones/ tests/ | |
| ``` | |
| 4. **Update the CHANGELOG.md** under the `[Unreleased]` section | |
| in the appropriate category (Added / Changed / Fixed / | |
| Deprecated / Security). | |
| 5. **Push and open a PR** against `main`. | |
| ## What we look for in a PR | |
| - **Clear motivation** in the PR description: what problem does | |
| this solve, why this approach. | |
| - **Tests** that exercise the new code path. | |
| - **Documentation** updates (README, SPECS, user/dev guides) when | |
| relevant. The CI doc-consistency tests (`tests/docs/`) will fail | |
| if you add a new engine, CLI command or endpoint without | |
| updating the README tables. | |
| - **Editorial neutrality** in the narrative engine: factual | |
| statements only, no recommendations (cf. CLAUDE.md philosophy). | |
| ## What we don't accept | |
| - **Breaking changes** without a major version bump and 2-version | |
| deprecation notice. | |
| - **Bare `except Exception: pass`** — replace by | |
| `logger.warning("[module] degraded feature: %s", e)`. | |
| - **Hardcoded UI strings** — use the i18n mechanism (see | |
| `docs/developer/extending-i18n.md` — French canonical). | |
| - **Commits with `--no-verify`** — bypassing pre-commit hooks is | |
| detected by the CI `precommit.yml` workflow. | |
| ## Reviewing | |
| PRs are reviewed by the maintainer(s) listed in `.github/CODEOWNERS` | |
| for the path you touched. Best-effort SLO of 7 working days for | |
| the first review (cf. `GOVERNANCE.md`). | |
| The reviewer may ask: | |
| - to split a large PR into smaller logical units ; | |
| - to refactor for circular dependency cleanliness ; | |
| - to add an editorial note in the synthesis (anti-hallucination | |
| test will catch any fancy derived metric not present in input). | |
| ## Code of conduct | |
| All interactions on the project are governed by our | |
| [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md) (Contributor Covenant | |
| 2.1). In short: be kind, accept constructive feedback gracefully, | |
| focus on what's best for the community. | |
| ## Reporting a security issue | |
| **Don't** open a public GitHub issue for security problems. See | |
| [`SECURITY.md`](SECURITY.md) for the responsible disclosure | |
| procedure. | |
| ## Licensing of your contribution | |
| By submitting a PR, you agree that your contribution will be | |
| licensed under the same license as the project (Apache-2.0). | |
| ## Help and questions | |
| - Quick questions: open a GitHub Discussion. | |
| - Bug reports: open a GitHub Issue with reproduction steps. | |
| - Architecture decisions / philosophical changes: open a | |
| Discussion first to gauge consensus before writing code. | |