Good starting points:
- Tools you already use and understand
- Libraries with < 500 GitHub stars (maintainers are hungry for help)
- Projects with active maintainers (last commit < 30 days ago)
- Projects that have a CONTRIBUTING.md (maintainer has invested in onboarding)
- Projects with "good first issue" or "help wanted" labels

Discovery:
- https://goodfirstissue.dev — curated good-first-issues
- https://github.com/explore — trending by language/topic
- https://up-for-grabs.net — issues specifically for new contributors
- Issues in repos you already star or watch

# Check contribution velocity
gh api repos/{owner}/{repo} --jq '{
  open_issues: .open_issues_count,
  stars: .stargazers_count,
  last_push: .pushed_at,
  license: .license.spdx_id
}'

# Check PR merge rate (are contributions actually accepted?)
gh pr list --repo {owner}/{repo} --state merged --limit 20

# Check how long PRs stay open
gh pr list --repo {owner}/{repo} --state open --limit 20 --json createdAt,title \
  | jq '.[] | {title, days_open: (now - (.createdAt | fromdateiso8601)) / 86400 | floor}'

# 1. Fork the repository on GitHub (creates your copy at github.com/yourusername/repo)

# 2. Clone YOUR fork (not the original)
git clone git@github.com:yourusername/repo.git
cd repo

# 3. Add the original repo as "upstream"
git remote add upstream git@github.com:originalowner/repo.git

# Verify
git remote -v
# origin    git@github.com:yourusername/repo.git (fetch)
# origin    git@github.com:yourusername/repo.git (push)
# upstream  git@github.com:originalowner/repo.git (fetch)
# upstream  git@github.com:originalowner/repo.git (push)

# 4. Create a branch for your work (never work on main directly)
git checkout -b fix/issue-123-null-pointer
# or
git checkout -b feat/add-retry-logic

# Sync your local main with upstream
git fetch upstream
git checkout main
git merge upstream/main   # or: git rebase upstream/main

# Push the synced main to your fork
git push origin main

# If you have an in-progress branch, rebase it
git checkout fix/issue-123-null-pointer
git rebase upstream/main
# Resolve any conflicts, then:
git push origin fix/issue-123-null-pointer --force-with-lease

1. Find an issue that's labeled "good first issue" or "help wanted"
2. Comment: "I'd like to work on this. I'm thinking of [approach]. Does that sound right?"
3. Wait for maintainer confirmation before starting
4. Only then write code

# Get an overview
ls -la
cat README.md
cat CONTRIBUTING.md
cat CHANGELOG.md  # understand version cadence

# Understand the test structure
find . -name "*.test.*" | head -20
find . -name "*.spec.*" | head -20

# Run the tests to make sure they pass on main before you start
npm test        # or: yarn test, pytest, go test ./..., cargo test

# Find the code related to your issue
grep -r "functionName" --include="*.ts" src/

gh pr list --repo {owner}/{repo} --state merged --limit 10
gh pr view {PR_NUMBER} --repo {owner}/{repo}

# Conventional commits format
git commit -m "fix(auth): handle null token in middleware

When the Authorization header is missing entirely (as opposed to
malformed), the middleware was throwing a TypeError instead of
returning a 401 response.

Fixes #123"

# Format: type(scope): subject
# Types: feat, fix, docs, style, refactor, test, chore, ci
# Body: wrap at 72 chars, explain WHY not what
# Footer: reference issue numbers

## What this PR does

Fixes #123 — `UserService.authenticate()` throws `NullPointerException` when
called with an expired token. The token parser returns `null` for expired tokens
but the caller assumed it always returned a User object.

## Why

The error was reported by two separate users who were logged out mid-session.
The fix adds an explicit null check before accessing token fields.

## How

- Added null guard in `authenticate()` before calling `token.getUserId()`
- Returns `null` (unauthenticated) instead of throwing
- Updated the caller in `AuthMiddleware` to handle the null return

## Testing

- Added unit test `authenticate_returns_null_for_expired_token`
- Manually tested with a token expired 1 hour ago

## Checklist

- [x] Tests added/updated
- [x] Documentation updated (if applicable)
- [x] Follows project code style
- [x] Linked to issue #123

Single responsibility: one PR, one problem.

Too big:
- "Add retry logic and fix auth bug and update dependencies"

Just right:
- "Fix null pointer in auth middleware (#123)"
- "Add retry logic to HTTP client (#456)"
- "Update lodash to 4.17.21 (#457)"

Small PRs:
- Get reviewed faster (reviewers can do it in 5 minutes)
- Have higher merge rates
- Are easier to revert if something goes wrong
- Build trust incrementally

Reviewer: "This approach won't work because of X edge case"

Wrong response: "I think it's fine because Y"
Right response: "Good catch! I hadn't considered X. 
                 I'll update the test to cover it and 
                 fix the implementation."

Reviewer: "Can you split this into two functions?"

Wrong response: Ignore it or argue
Right response: Do it, or ask "I can split it, but I 
                wanted to keep them together because 
                they share state Z. Would a helper 
                function be OK instead?"

# Push additional commits (don't force-push during review unless asked)
git add src/auth/middleware.ts
git commit -m "fix: handle edge case from review feedback"
git push origin fix/issue-123-null-pointer

# After all feedback is addressed, you may be asked to squash
git rebase -i upstream/main
# In interactive rebase, mark commits after the first as 'squash'
git push origin fix/issue-123-null-pointer --force-with-lease

After 1 week with no response:
  Comment: "Friendly ping — is there anything else needed from my side?"

After 2 weeks with no response:
  Comment: "I notice this hasn't had activity. Is this still something the 
            project is interested in? Happy to close it if priorities have 
            shifted."

After 1 month with no response:
  Move on. Close the PR with a note: "Closing due to inactivity. 
  Happy to reopen if the project wants to revisit this."

Month 1: Fix two small bugs. Leave helpful comments on other issues.
Month 2: Review PRs from other contributors. You don't have to approve—
         ask clarifying questions, share observations.
Month 3: Tackle a medium feature with maintainer buy-in up front.
Month 4+: You'll be tagged in relevant issues. You understand the codebase.
          Some maintainers will add you as a collaborator.

# Reproduce and confirm bugs reported by others
git checkout upstream/main
# Try to reproduce the reported issue
# Comment: "Confirmed on main with Node 20. Steps to reproduce: ..."

# Help triage by asking for missing information
# "Could you share the error message and which version you're using?"

# Link related issues
# "This seems related to #234 which was closed. The difference is..."

# Generate a contribution summary for your resume
gh api user/repos --jq '.[].full_name' | while read repo; do
  gh pr list --author @me --repo "$repo" --state merged --limit 100 2>/dev/null
done

# Star projects you've contributed to (shows engagement)
gh api -X PUT user/starred/{owner}/{repo}