Picarones / CONTRIBUTING.en.md
Claude
docs: remove sprint narrative from root files (Phase 2 L1)
b98dad4 unverified
<!-- 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.