Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
105 lines (78 loc) · 2.8 KB

CONTRIBUTING.md

File metadata and controls

105 lines (78 loc) · 2.8 KB

Contributing

Import Guidelines

Rule: Always use relative imports.

Bad:

import X from "src/components/X";

Good:

import X from "../../components/X";

CI will reject PRs containing src/* imports.

Issue/PR: https://github.com/MindBlockLabs/mindBlock_app/pull/0000 (placeholder)

MUST RUN Local check to before submitting a pr:

npm ci
npm --workspace frontend run build
npm --workspace backend run build

npm --workspace frontend run lint
npm --workspace backend run lint

npm --workspace frontend exec -- tsc --noEmit -p tsconfig.json
npm --workspace backend exec -- tsc --noEmit -p tsconfig.json

Contract Development

Prerequisites

Install the following tools before working on contracts:

# Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Add wasm32-unknown-unknown target
rustup target add wasm32-unknown-unknown

# Install Stellar CLI
cargo install --locked stellar-cli

MUST RUN Local checks from inside contracts/ before submitting a PR:

cd contracts/

# Check formatting
cargo fmt --check

# Build the contract
stellar contract build

# Run tests
cargo test

Branch Protection

main and develop require status checks: lint-imports, build, type-check, contracts. Require branches to be up-to-date before merging.

Pull Request Standards

To maintain a clean commit history and make reviews efficient, all pull requests must meet the following requirements:

Branching Convention

  • Use descriptive branch names:
    • feature/your-feature-name
    • fix/issue-number
    • chore/tooling-update
  • Avoid vague names like update or patch.

PR Title

  • Must follow Conventional Commits style:
    • Format: <type>(optional-scope): short description (#issue-number)
    • Allowed types: feat, fix, docs, chore, test, refactor, ci
  • Examples:
    • fix(streaks): use user timezone for date strings (#241)
    • feat(auth): add refresh token support (#250)
    • docs(contributing): clarify PR standards (#234)

PR Description

  • Must provide enough context for maintainers to understand the change without reading every line of code.
  • Minimum requirements:
    • Problem: What issue does this PR solve?
    • Solution: How was it solved?
    • Acceptance Criteria: What conditions prove the fix works?
    • Testing Notes: How was it tested?
  • Avoid minimal descriptions like only writing Closes #22.

CI/CD Enforcement

  • The CI pipeline will automatically reject PRs that:
    • Have non-compliant titles (e.g., update, fix bug).
    • Have descriptions shorter than 20 characters or missing context.
  • The build-and-deploy job depends on PR validation, so failing validation will block merges.

By following these standards, contributors ensure their PRs are clear, maintainable, and easy to review.