Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
85 lines (58 loc) · 2.96 KB

CONTRIBUTING.md

File metadata and controls

85 lines (58 loc) · 2.96 KB

Contributing to Sprout

Project State

Sprout is currently establishing its public project baseline. Early contributions will often be documentation, API design, architecture, and scaffolding work rather than feature-complete runtime code.

Ways to Contribute

  • improve product, architecture, and operator documentation
  • refine API contracts and data models
  • propose ADRs for major design choices
  • implement foundational runtime modules
  • add tests, examples, or local development tooling

Ground Rules

  • keep the platform API-first
  • preserve a small, well-bounded core
  • prefer explicit interfaces over hidden coupling
  • avoid introducing license or dependency choices that constrain future reuse
  • document operator-facing behavior and security implications alongside implementation changes

Recommended Workflow

  1. Open or refine the relevant issue, design note, or architecture discussion.
  2. Check the product docs and ADRs to confirm the intended direction.
  3. Update docs and API contracts when the behavior or interface changes.
  4. Keep changes focused and easy to review.
  5. Add or update tests when code is introduced.

Change Types

Documentation Changes

Documentation changes should:

  • stay consistent with the product baseline in docs/
  • clearly distinguish current repository state from target platform design
  • avoid implying implemented behavior that does not yet exist

API Changes

API changes should:

  • update api/openapi.yaml
  • explain compatibility impact
  • note new resources, fields, enums, or error behavior
  • update relevant docs in docs/product/ or docs/architecture/

Runtime Changes

Runtime changes should:

  • preserve module boundaries between core logic and hardware-facing execution
  • prefer Go for core services unless there is a documented reason not to
  • include tests appropriate to the layer being changed

Style and Design Expectations

  • favor small, focused files and clear interfaces
  • prefer stable, explicit schemas over ad hoc payloads
  • avoid embedding vendor-specific behavior in core domain models
  • treat site-local execution as a delegated concern, not a shortcut around the control plane
  • treat security, auditability, and operator safety as product features

Commit and PR Guidance

  • use small, reviewable commits when possible
  • write commit messages that explain intent, not just file changes
  • explain user-facing or operator-facing impact in the PR description
  • call out follow-up work instead of hiding it in partial implementations

Review Checklist

Before asking for review, confirm that you have:

  • updated the relevant docs
  • updated the OpenAPI contract if the public API changed
  • called out any new security assumptions
  • noted any compatibility or rollout risk
  • verified that links and paths in new docs are valid

Licensing

By contributing, you agree that your contribution is intended for inclusion in an Apache-2.0 licensed project unless the repository policy is updated explicitly.