Contributing to Errium¶
Thank you for your interest in contributing to Errium! As an open-source project, we welcome community feedback, feature requests, bug reports, and pull requests.
๐ ๏ธ Development Setup¶
Errium utilizes the high-performance Python package manager uv to manage virtual environments and lockfiles.
-
Clone the repository:
-
Sync development dependencies:
-
Install the package in editable mode:
๐งช Testing¶
We mandate high code coverage on all core operations. Ensure that your changes have appropriate unit and integration tests under the tests/ directory.
Run the test suite using pytest:
To run tests and capture short traceback outputs:
๐งน Code Style & Linting¶
We enforce PEP8 compliance, strong static typing, and structural cleanliness.
Run the linter and format checker via ruff:
๐ Documentation¶
The documentation site is built with mkdocs + mkdocs-material from mkdocs.yml, pulling its
pages directly from this repo's root .md files (docs/*.md are symlinks โ edit the root files,
not the symlinks).
Preview it locally:
Build the static site (output goes to site/, which is gitignored):
๐ท๏ธ Commit Message Conventions¶
We adhere to the standard Angular Git commit message style:
- feat: A new feature (e.g.
feat(core): implement validation beautifier). - fix: A bug fix (e.g.
fix(fastapi): correct HTTPException status mapping). - docs: Documentation-only changes (e.g.
docs(readme): add usage examples). - style: Changes that do not affect code logic (whitespace, formatting, missing semi-colons).
- refactor: Code changes that neither fix bugs nor add features.
- test: Adding missing tests or correcting existing tests.
๐ฟ Branch Naming Rules¶
Maintain descriptive branch names prefixing the context:
- Features:
feature/short-descorfeat/short-desc - Bug fixes:
bugfix/short-descorfix/short-desc - Documentation:
docs/short-desc
๐ค Pull Request Rules¶
Before submitting your pull request:
1. Ensure the code passes all unit and integration tests.
2. Confirm there are no lingering lint errors (uv run ruff check .).
3. Keep the changes minimal and focused. Do not combine multiple unrelated features into a single PR.
4. Add clear descriptions of what the change does and why it was needed.