@@ -10,43 +10,58 @@ We value **incremental, detail‑first contributions** over big rewrites or abst
1010## 2. Code & Commit Conventions
1111
1212- ** Conventional Commits**
13- Follow < https://www.conventionalcommits.org/en/v1.0.0/ > :
14- - ` feat: … ` for new features
15- - ` fix: … ` for bug fixes
16- - ` chore: … ` for maintenance
13+ Follow < https://www.conventionalcommits.org/en/v1.0.0/ > :
14+ - ` feat: ` for new features
15+ - ` fix: ` for bug fixes
16+ - ` chore: ` for maintenance or tooling
1717
1818- ** Logical Commits**
19- Group changes by purpose. It’s okay to have multiple commits in a PR, but if they’re mere checkpoints, squash them into a single logical commit.
20-
21- - ** Lint & Tests**
22- Run existing linters/formatters and ensure all tests pass.
19+ Group changes by purpose. Multiple commits are fine, but avoid noise. Squash when appropriate.
20+
21+ - ** Python Formatting & Style**
22+ - Use ** [ Black] ( https://black.readthedocs.io/ ) ** for consistent code formatting.
23+ - Black is opinionated: don't argue with it, just run it.
24+ - Line length is set to ** 88** , matching the default.
25+ - Use ** [ flake8] ( https://flake8.pycqa.org/en/latest/ ) ** for static checks.
26+ - Line length also set to 88.
27+ - Some flake8 warnings are disabled (e.g. ` E203 ` , ` W503 ` ) to avoid conflicts with Black.
28+ - Run ` black . ` and ` flake8 ` before submitting.
29+ - Use Python ** 3.13.x** for local testing and formatting.
30+
31+ - ** Testing**
32+ - Run ` pytest ` before pushing.
33+ - Ensure coverage isn’t regressing.
2334
2435## 3. Pull Request Workflow
2536
2637- ** One logical change per PR.**
27- - ** Rebase or squash** before opening to keep history concise .
38+ - ** Rebase or squash** before opening to keep history clean .
2839- ** Title & Description**
29- - Title uses Conventional Commits style .
30- - Description explains _ what_ and _ why_ —keep context minimal .
40+ - Use Conventional Commit format .
41+ - Explain _ what_ and _ why_ concisely in the PR body .
3142
3243## 4. Issue Reporting
3344
34- - Search existing issues first.
35- - Provide a minimal reproducible example and clear steps.
45+ - Search open issues before creating a new one.
46+ - Include clear steps to reproduce and environment details.
47+ - Prefer ** focused** issues—don’t bundle multiple topics.
3648
3749## 5. Automation & Checks
3850
39- We enforce quality via CI on every push and PR :
51+ All PRs and pushes go through CI :
4052
41- - ** Commitlint** for commit‑message style
42- - ** Linters/Formatters**
43- - ** Unit tests**
53+ - ** Commitlint** for commit style
54+ - ** Black** for formatting
55+ - ** flake8** for static checks
56+ - ** pytest** with coverage
4457
45- Failures must be fixed before review .
58+ PRs must pass all checks to be reviewed .
4659
4760## 6. Code of Conduct & Support
4861
49- - Please see ` CODE_OF_CONDUCT.md ` for behavioral expectations and reporting.
50- - For quick questions or discussions, open an issue with the ` discussion ` label or mention a maintainer.
62+ - See ` CODE_OF_CONDUCT.md ` for guidelines and reporting.
63+ - For questions or planning, open an issue and use the ` discussion ` label, or mention a maintainer.
64+
65+ ---
5166
52- Thanks again for helping keep this project small, simple , and impactful!
67+ Thanks again for helping keep this project small, sharp , and focused.
0 commit comments