First PR
Pick a tiny issue, run the check, open a PR with proof.
> beginner_open_source/program
Get your first open-source PR merged.
A guided GitHub lab for first pull requests, real maintainer feedback, clean checks, and a visible path from first merge to second contribution.
> choose_your_entry_point
Issue Finder
Pick your skill and time. The site builds a GitHub search link that feels made for you.
Suggested route
30 minute docs task
Improve one guide, example, or checklist with a focused pull request.
Open matching issues> live_feed
Live Good First Issues
Real-time feed of open issues ready to be claimed. Type .take on GitHub to auto-assign.
> fetching open issues from GitHub API...
Loading...
> contributor_journey
From first PR to trusted contributor
The repo is designed as a progression path, not a one-time task list.
First Merge
Get visible proof on the First Merge Wall after review.
Second PR
Move into a stronger task: CLI, testing, docs structure, or issue quality.
Trust Builder
Help another beginner, improve an issue, or answer a discussion clearly.
> before_you_touch_code
The first PR workflow
Most beginners do not fail because they cannot code. They get lost in the process. This path keeps the next step visible.
git clone https://github.com/P-r-e-m-i-u-m/open-source-starter-lab.git
cd open-source-starter-lab
npm install
npm run checkRead the issue
Use the decoder to find the first file, first command, and what not to change.
Claim one task
Comment before starting so nobody duplicates the same work.
Ship with proof
Keep the PR small and include the check output so review is faster.
> live_proof_layer
Built around evidence
> trust_passport_layer
Get proof people can read
After a real PR is merged, contributors get a public passport file that records the skill, PR, linked issue, and next step.
Open Source Trust Passport
@new-contributor
- Level 1 - First PR Contributor
- First merged PR: #123
- Primary skill: docs, testing, CLI, or website
- Proof: reviewed merge with checks
Why it stands out
Most beginner repos stop after the merge. This repo turns the merge into a public proof artifact contributors can share and maintainers can trust.
Read passport system> why_people_trust_it
No silent maze
The repo is built around signals contributors look for before spending time: active review, clear instructions, visible proof, and a next step after merge.
Review readiness
The PR Welcome Guard checks summaries, testing notes, and `npm run check` so first PRs are easier to review.
Open coordination
Issues, discussions, queues, and merge proof stay public so contributors can see how work moves.
Second-step support
After merge, contributors get route suggestions instead of being left wondering what to do next.
> maintainer_os
Human-feeling automation
Automation handles the repetitive guidance so maintainers can focus on thoughtful review.
Daily Issue Bot
Creates beginner-friendly starter issues from a curated maintainer backlog.
PR Welcome Guard
Welcomes contributors and checks whether the PR is review-ready.
Contributor Queue
Shows who is assigned, stuck, ready for follow-up, or waiting for help.
After Merge Proof
Thanks contributors, closes linked issues, and suggests a next useful path.
> product_surface
The website is becoming the front door
The repo stays useful for GitHub workflows, but the website is the main product surface for people who want to discover the path before touching code.
Discover
Visitors choose by skill, time, and confidence instead of reading a long issue list.
Contribute
The site points people to the exact GitHub issue, command, and proof checklist.
Prove
Trust Passports, spotlights, and the dashboard turn merged work into public evidence.
Issue quality: curated
Passports: verified
Monthly spotlight: active
Automation health: dry-run checked> beginner_questions
FAQ for the nervous first PR
Do I need to be an expert?
No. Start with docs, examples, setup guides, issue clarity, or one tiny CLI/test improvement.
What if the issue is confusing?
Use the First Issue Decoder or ask in the weekly assignment thread with your skill and time.
What should my PR include?
Say what changed, why it helps, how you tested it, and link the issue with `Closes #...` when relevant.
What if checks fail?
Paste the command, the error, and what you expected. Clear failure notes are useful maintainer signals.
> ready_when_you_are