Thanks for your interest in contributing.
This guide defines the expected contribution workflow for the nebulex core
repository.
This repository contains Nebulex core. Adapter projects (for example
nebulex_local, nebulex_distributed) are maintained in sibling repositories
and have their own contribution rules.
- Read
README.md. - Follow the "Session Bootstrap" in
usage-rules/workflow.md, the source of the coding and review conventions used in this repo.
Use the issue tracker for bug reports and feature discussions:
When opening a bug report, include:
- Elixir and OTP versions
- Nebulex version/branch
- Minimal reproduction steps
- Expected vs actual behavior
Feature proposals are welcome.
For non-trivial features, open an issue first before implementing code so scope and design can be aligned early.
When proposing a feature, include:
- Problem statement.
- Real-world use case.
- Proposed API/behavior.
- Alternatives considered.
Open pull requests at:
- Keep changes focused and avoid unrelated commits.
- Add or update tests with code changes.
- Update documentation when behavior changes.
- Do not update CHANGELOG.md directly; include release-note context in the PR description for maintainers.
- Reference related issues (for example,
Closes #123).
Run targeted checks during development and run the full CI command before requesting review:
# quick targeted check
mix test path/to/changed_test.exs
# full validation
mix precommitCommit messages must follow Conventional Commits:
type(scope): short summary
Examples:
feat(cache): add runtime option validation for ttlfix(decorators): handle nested context pop safelydocs(workflow): add contribution and review checklist
For @doc, @moduledoc, and @typedoc, keep the first paragraph short and
summary-oriented. Add examples when possible, ideally doctest-friendly.
By submitting a contribution, you agree that your work is licensed under the project's MIT license.