kugetsu/CONTRIBUTING.md

Contributing

Workflow

1. Create a branch for your work: git checkout -b fix/issue-N-name or git checkout -b feat/issue-N-feature-name
2. Make changes and commit with clear messages
3. Open a Pull Request for review
4. Do not merge directly to main or develop for reviewable changes
5. After approval, squash and merge

Guidelines

• Use clear, descriptive commit messages
• Keep PRs focused and reasonably sized
• Document any non-obvious decisions
• Test changes before submitting
• See VERSIONING.md for backport compatibility rules

Branches

Primary Branches

• main — stable 0.1.x releases, production-ready code
• develop — experimental 0.2.x work, next major version

Feature Branches

• fix/* — bug fixes
• feat/* — new features
• docs/* — documentation updates
• refactor/* — code refactoring (no behavior change)

Branch Model

main (0.1.x stable)
  └── v0.1.0, v0.1.1, v0.1.2, ...

develop (0.2.x experimental)
  └── (next major version work)

Which Branch to Target?

Change Type	Target Branch	Backport?
Bug fix	main	N/A
Documentation	main	N/A
New feature (backport-compatible)	main	Can cherry-pick to develop
Experimental feature	develop	No
Breaking change	develop	No

Backport Compatibility

Before merging, consider if your change is backport-compatible:

• YES: Bug fixes, docs, adding new optional inputs
• NO: Changing behavior, changing defaults, removing features

See VERSIONING.md for full policy.

Release Process

1. Bug fixes and docs → directly to main
2. New features → develop or feature branches → develop
3. When develop is stable enough → merge to main for release