- Community
- Contributing Guide
Community
Contributing Guide
How to propose changes, report bugs, and submit pull requests to Mako Code.
Contributing Guide
We welcome—and rely on—community contributions. This guide outlines the development workflow, style conventions, and review process.
1. Issue Tracker
- Bug Report – Provide reproduction steps and stack traces. Attach sample Parquet if relevant.
- Feature Request – Describe the use-case, not just the solution. Explain why existing workflows are insufficient.
Labels:
| Label | Meaning |
|---|---|
bug | Unexpected behavior, failing tests |
enhancement | Backwards-compatible feature |
breaking | API change requiring major version bump |
2. Development Environment
Follow the Installation Guide (source checkout path). Clone your fork and create a topic branch:
git checkout -b feat/my-improvement
Run both servers in watch mode:
(cd backend && uvicorn main:app --reload --port 8001)
(cd frontend && npm run dev)
3. Coding Standards
3.1 Python
- Formatter: Black (line length 88). Run
uv pip install blackif needed. - Linter: Ruff – CI fails if
ruff --quietreports issues. - Type Hints: Use
typing.Literal,Path, etc. MyPy is optional but appreciated.
3.2 TypeScript / Svelte
- Prettier: auto-formated on commit.
- ESLint: Config in
frontend/eslint.config.js. - Component files should stay under 300 lines unless unavoidable.
4. Commit Messages
<type>(scope): short summary
Body explaining *what* and *why* (not *how*). Reference issues.
Examples:
feat(frontend): add theme switcher (#42)
fix(backend): handle empty DataFrame edge-case (#55)
5. Testing
- Backend unit tests should live under
backend/tests/(PyTest). - Front-end unit tests (Vitest) under
frontend/src/lib/__tests__/. - Use “Golden Files” for serialization outputs where appropriate.
CI runs via GitHub Actions. Push to your branch; the pipeline must turn green before review.
6. Documentation
All user-facing changes require corresponding docs updates under docs/ (this site). We use MDX; code blocks auto-highlight via Prism.
7. Pull Request Lifecycle
- Draft PR against
main. - At least one core maintainer review.
- Squash-merge using GitHub UI.
- Release notes updated in
CHANGELOG.md(maintainers will handle if you include a# Changelogsection in PR description).
8. Code of Conduct
Be respectful and constructive. We follow the Contributor Covenant v2.1.
9. Community
- Discussions Tab – Propose ideas or ask usage questions.
- Matrix/Slack – Coming soon. Suggest your preference in an issue.
Thank You
Every merged PR is credited in the release notes. Your name, handle, or corporate affiliation will appear unless you opt out.