Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
59 lines (46 loc) · 2.19 KB

CONTRIBUTING.md

File metadata and controls

59 lines (46 loc) · 2.19 KB
Raw

Contributing to MiHashport Contract

Thanks for considering a contribution to the Soroban contracts behind MiHashport. This repo moves real (eventually mainnet) funds, so we keep contributions small, reviewed, and scoped to a single tracked issue.

Finding work

  • Maintainers turn docs/PLAN.md into individual GitHub issues. Don't start work that isn't tracked by an issue — open one first if you see a gap.
  • Comment on the issue to get assigned before you start working. This avoids two people duplicating the same contract logic.
  • Look for the good first issue label if you're new to Soroban or to this codebase.

Workflow

  1. Fork the repo.
  2. Branch off main:
    • feat/<issue-number>-short-name for new functionality
    • fix/<issue-number>-short-name for bug fixes
  3. Make your change, addressing exactly one issue.
  4. Open a PR against main using the PR template, with a Closes #<issue> line.

Commit messages

  • Single-line, imperative mood: Add unregister entrypoint to identity-registry, not Added or Adding.
  • No Co-authored-by lines.
  • One commit per issue where practical.

Code style

  • Idiomatic Rust; run cargo fmt before committing.
  • Contract entrypoints return Result<T, Error> using the contract's #[contracterror] enum — don't panic!/unwrap on user-controllable input.
  • Every new entrypoint needs a corresponding test in src/test.rs using soroban_sdk::testutils (see identity-registry for the pattern: Env::default(), mock_all_auths(), try_* client methods for expected-failure cases).
  • Keep contracts #![no_std]-compatible — don't pull in std-only crates.
  • Storage keys go through a single #[contracttype] enum DataKey, not ad hoc string keys.

CI

CI must be green (build + test) before a PR will be reviewed. If CI is failing for a reason unrelated to your change, say so in the PR description rather than trying to silently work around it.

Review

Be respectful and patient — maintainers review in the order issues were scoped, not the order PRs arrive. Maintainers may close PRs that are stale, out of scope for their linked issue, or that reimplement work already in progress elsewhere.