Getting Started with Contributing

Ready to contribute? Here’s how to get started!

This guide walks you through making your first contribution to OpenScan.AI, from finding an issue to submitting your pull request.

Step 1: Find something to work on

Browse issues across the OpenScanAI GitHub organization:

  • Look for the good first issue label — these are scoped for newcomers and usually include implementation hints.
  • help wanted issues are larger but well-defined.
  • Documentation issues on the website repo are the fastest way to land a first PR.

If you have your own idea — a bug you hit, an API endpoint you wish existed — open an issue first to discuss it before writing code. That avoids duplicated effort and surfaces design constraints early.

Step 2: Set up your environment

Pick the setup guide for the area you’re contributing to:

Step 3: Fork and branch

Terminal window
# Fork the repository on GitHub, then:
git clone https://github.com/YOUR-USERNAME/REPO.git
cd REPO
git remote add upstream https://github.com/OpenScanAI/REPO.git


# Create a descriptive branch
git checkout -b fix/token-holder-pagination

Branch naming conventions:

  • fix/... — bug fixes
  • feat/... — new features
  • docs/... — documentation changes
  • chore/... — tooling, dependencies, cleanup

Step 4: Make your change

  • Follow the Code Conventions.
  • Add or update tests where the repository has them.
  • Keep the diff focused — unrelated refactors belong in their own PR.

Step 5: Commit

Use the conventional commit format:

Terminal window
git commit -m "fix: correct token holder pagination cursor"

Common types: fix, feat, docs, chore, refactor, test.

Step 6: Submit the pull request

Push your branch and open a PR against the repository’s default branch:

Terminal window
git push origin fix/token-holder-pagination

In the PR description, include:

  1. What changed and why (link the issue: Closes #123).
  2. How to test — commands, requests, or UI steps a reviewer can run.
  3. Screenshots for any UI change.

Then follow the Pull Request Process through review to merge.

What makes a great first PR

  • Small. A 20-line fix with tests beats a 500-line refactor.
  • Verified. You ran the tests and/or the dev server and saw it work.
  • Documented. If behavior changed, the docs changed too — see the Documentation Guide.

After your first merge

  • Add yourself to ongoing discussions in areas you care about.
  • Pick up a help wanted issue for a deeper contribution.
  • Review other PRs — reading code is the fastest way to learn the codebase.
Edit page on github
Guides Backend & Indexer Setup