Skip to content

FIRST-PR.md

Latest commit

 

History

History
210 lines (157 loc) · 5.69 KB

FIRST-PR.md

File metadata and controls

210 lines (157 loc) · 5.69 KB
title Your First PR
description A step-by-step guide to making your first contribution to Signet.
order 25
section Project

Your First PR

This guide walks you through making your first pull request to Signet. No prior git or GitHub experience required.

If you get stuck at any point, ask in Discord or open a Discussion. We are happy to help.

What you'll need

  • A GitHub account
  • Git installed on your machine
  • Bun installed (Signet's package manager)
  • A code editor (VS Code, neovim, whatever you prefer)

If git is brand new to you, check out the Silly Git Guide for a beginner-friendly introduction to the basics.

Step 1: Fork the repo

A "fork" is your own copy of Signet on GitHub. You'll make changes there, then propose them back to the main project.

  1. Go to github.com/Signet-AI/signetai
  2. Click the Fork button (top right)
  3. GitHub creates a copy under your account

Step 2: Clone your fork

This downloads your fork to your machine so you can work on it locally.

# Replace YOUR-USERNAME with your GitHub username
git clone https://github.com/YOUR-USERNAME/signetai.git
cd signetai

Then add the original repo as a remote called "upstream" so you can stay in sync:

git remote add upstream https://github.com/Signet-AI/signetai.git

Step 3: Install and build

bun install
bun run build

If both of those succeed, you're ready to go. If something fails, ask in Discord and we'll sort it out.

Step 4: Create a branch

Never work directly on main. Create a branch that describes what you're doing:

git checkout -b fix/typo-in-readme

Branch naming conventions:

  • fix/short-description for bug fixes
  • feat/short-description for new features
  • docs/short-description for documentation changes
  • refactor/short-description for code cleanup

Step 5: Make your changes

Edit the files you want to change. If this is your very first PR, pick something small. Good first contributions:

  • Fix a typo or clarify wording in docs
  • Improve an error message
  • Add a missing test case
  • Address an open issue labeled good first issue

Browse open issues for ideas, or bring one of your own.

Step 6: Verify your changes

Before committing, make sure nothing is broken:

bun run build       # does it still build?
bun test            # do the tests pass?
bun run lint        # any lint issues?
bun run typecheck   # any type errors?

Fix anything that comes up. If you're unsure about a failure, ask.

Step 7: Commit your changes

Stage the files you changed and write a commit message:

git add path/to/changed-file.ts
git commit -m "fix(docs): correct typo in quickstart guide"

We use conventional commits. The format is type(scope): description. Common types:

Type When to use
fix Bug fix or correction
feat New user-facing feature
docs Documentation only
refactor Code change that doesn't fix a bug or add a feature
test Adding or updating tests
chore Maintenance, config, tooling

Keep the message short (under 50 characters for the subject line) and use present tense ("fix typo" not "fixed typo").

Step 8: Push to your fork

git push origin fix/typo-in-readme

If git asks you to set an upstream, just run the command it suggests.

Step 9: Open a pull request

  1. Go to your fork on GitHub. You should see a banner saying "Compare & pull request." Click it.
  2. Fill in the PR template:
    • Title: short and descriptive, like your commit message
    • Description: explain what you changed and why. Link any related issues with Fixes #123 or Closes #123.
  3. Click Create pull request

That's it. A maintainer will review your PR, leave feedback if anything needs adjusting, and merge it when it's ready.

What happens after you submit

  • CI runs automatically (build, lint, typecheck, tests). If something fails, click the red X to see what went wrong.
  • A reviewer may request changes. This is normal and not a judgment on you. Push new commits to the same branch and the PR updates automatically.
  • Once approved and merged, your contribution shows up in the git history and you'll be added to the contributors list.

Keeping your fork in sync

Before starting new work, pull the latest from upstream:

git checkout main
git pull upstream main
git push origin main

Then create a new branch from the updated main for your next change.

Ways to contribute beyond code

Not every contribution is a pull request. These are all valuable:

  • Report bugs: Open an issue with steps to reproduce
  • Suggest features: Start a Discussion or open an issue
  • Improve docs: Typos, unclear sections, missing examples
  • Test and give feedback: Run Signet and tell us what's confusing, broken, or missing
  • Answer questions: Help others in Discord or Discussions

Every contribution matters. The contributors list tracks merged code, but the project benefits from all of these.

Questions?