Contributing

Bug reports, questions and pull requests are welcome. Please open an issue before starting on a larger change, so that its design can be agreed first.

Development setup

$ git clone https://github.com/smarter-sh/smarter-types.git
$ cd smarter-types
$ make init

make init creates the repository’s own virtual environment, venv/, from the pinned requirements/local.txt, installs the package in editable mode, and installs the pre-commit hooks. make alone lists every command.

$ make test             # the tests
$ make coverage         # with a coverage report: at least 95%
$ make typecheck        # mypy
$ make lint             # the pre-commit hooks, on every file
$ make sphinx-build     # these docs, with warnings as errors

Pull requests

Fork the repository, and branch from main.
Make your change with its tests. make coverage must stay at 95% or more. CI checks this, on every supported Python version.
Update the docs and docstrings for anything a user can see.
Write conventional commits, e.g. feat(kinds): add the Orchestrator kind. Releases are versioned from them: fix makes a patch release, feat a minor one.
Open a pull request that says what changed and why, and links its issue.

A few rules keep the platform and the SDK in step. They are explained in the Architectural Decision Records:

Plain Python only: nothing here may need Django, Pydantic, settings or a database.
SAMKinds is the single source of truth for which kinds exist. Other enumerations take their values from it.
A new kind needs a place in SAMKinds.apply_order().
Removing or renaming a member, or changing a value, breaks the platform, the SDK, and manifests already written, so it needs a major release.

Code of conduct

Everyone who takes part is expected to follow the code of conduct. Governance of the Smarter projects is described in smarter-sh/community.