Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
47 lines (32 loc) · 2.45 KB

CONTRIBUTING.md

File metadata and controls

47 lines (32 loc) · 2.45 KB
Raw

Contributing to PipSync projects

Thank you for helping improve PipSync's public developer surface. Small, focused changes with tests and clear contract impact are easiest to review.

Before you begin

  1. Read the target repository's README and local contribution notes.
  2. Search existing issues and pull requests.
  3. For a substantial contract, dependency, or architecture change, open a proposal first.
  4. Use only synthetic, mock, or paper-trading data.

By participating, you agree to follow the CODE_OF_CONDUCT.md and the repository's license.

Development workflow

  1. Fork the repository and branch from its default branch.
  2. Make one coherent change. Preserve public compatibility unless the change follows the documented deprecation policy.
  3. Add or update tests and fixtures for behavior changes.
  4. Run the repository's documented validation commands.
  5. Open a pull request using the provided checklist and explain user-visible effects.

Do not commit generated credentials, .env files, private endpoints, production configuration, customer data, broker/account identifiers, copied production logs, private prompts, or certification evidence. Use reserved example domains, obvious placeholder tokens, and synthetic UUIDs. Examples must default to mock or paper behavior and must not place a live order implicitly.

Contract changes

For OpenAPI, JSON Schema, SDK, webhook, or CLI changes:

  • identify whether the change is additive, corrective, deprecated, or breaking
  • update fixtures, changelog, and migration notes together
  • keep authentication before persistence or side effects
  • keep idempotency keys stable across retries
  • avoid documenting an endpoint or guarantee that the published contract does not prove
  • use exact raw request bodies for signature verification where the provider requires it

Breaking changes require a new major contract version. Deprecations must remain usable for the period stated by the owning repository's version policy.

Commit and pull-request quality

Use clear, imperative commit subjects. A pull request should state:

  • the problem and intended outcome
  • affected public contracts
  • validation performed and its result
  • compatibility, security, and trading-safety considerations
  • follow-up work that is deliberately out of scope

Maintainers may close changes that expose sensitive data, bypass safety controls, make unsupported performance claims, or cannot be reproduced without private production access.