There is no bar to clear. There is a first pull request to open.
No interview, no test, no selection at the door. What follows is what the club actually looks for, the four steps everybody goes through, and an honest account of who tends to leave.
Never contributed before
Two ways in from zero.
01
Come to a hackathon or build day
No experience needed. You pair with a senior for the whole day.
Bring: A laptop and a GitHub account. That is genuinely it.
You have never contributed to open source and possibly never used Git for anything except pushing a college project. You are not sure you are good enough to be in the room. This path exists specifically for you, and it is how most of the club started.
What week one looks like
You turn up to a build day or one of our hackathons. Nothing to prepare, nothing to install beforehand — we will do the setup with you, because that is usually the part that defeats people alone.
You get paired with somebody who has already landed work upstream. You sit next to them, not in an audience.
Together you pick one open issue on a real project and read enough of the codebase to understand it. Reading is most of the work and nobody tells first-years that.
By the end of the day you have a branch, a change, and a rough idea of why the change is correct. Whether it is merged that day does not matter.
What you walk away with
A working local setup of a real project, one branch with a real change on it, and the name of a person you can message when you are stuck.
Our hackathons are not judged and nothing is ranked. They exist so that thirty people are stuck on the same setup problems in the same room, which is the fastest way past them.
02
First contribution sprint
A checklist, a club repo, and a reviewer who knows you are new.
Bring: A laptop, a GitHub account, and about four hours across the week.
You want a merged pull request with your name on it and you would rather work through a list than improvise. Docs fixes, typos, failing edge cases and good-first-issues on the club's own repositories — starting on our repos because the person reviewing your PR is somebody you can find in person and ask.
What week one looks like
We give you the checklist: fork, clone, build, find an issue with the good-first-issue label, claim it in a comment so nobody duplicates your work.
You make the change. Unglamorous is the point — a typo in the docs is a completely legitimate first contribution and always has been.
Your mentor reviews it before a maintainer does, so the version that gets opened is already close to mergeable.
You open the pull request. Then you find out that review comments are not criticism, which is the actual lesson of the week.
What you walk away with
One merged pull request, a public commit under your name, and the whole mechanical loop — fork, branch, PR, review, merge — done once so it stops being frightening.
Some experience already
Two ways in if you have done some of this.
03
Fast-track
Already contributing somewhere? Show us the PRs and skip the ramp.
You already have merged work in some project's repository, however small. There is no reason to put you through an introduction to Git. Send the links and you go straight onto a project team.
What week one looks like
Send us your merged pull requests. Not a resume — the PR links, so we can read the diffs and the review threads.
We talk for twenty minutes about what you want to be working on and what you are avoiding.
You join a project team directly, with a piece of work that is actually yours rather than a starter task.
You start reviewing other people's patches in your first week, because that is the fastest way to learn a codebase and the club needs reviewers more than it needs contributors.
What you walk away with
Ownership of a real piece of work, and a say in what the club builds. People on this path tend to end up maintaining something.
04
Program track
The GSoC/LFX prep cohort, with mentors who have been through it.
You are aiming at a paid programme — GSoC, LFX Mentorship, Outreachy — and you want to do it deliberately instead of writing a proposal the week it is due. Best joined six months before the application window, which for GSoC means starting in autumn.
What week one looks like
You pick two target organisations. Two, not one, because nobody reliably gets their first choice and the whole argument of this club is that these are competitive.
You read both projects' contribution guides and build both codebases locally. This week is unglamorous on purpose.
You find one small tractable issue in each and start on the first. The goal for the month is a merged patch in both, so the maintainers reading your application in March recognise your username.
You join the weekly cohort session, where people read each other's proposals and say the blunt thing about them.
What you walk away with
A months-long commit history in two organisations before applications open, a proposal that several people have already torn apart, and mentors who wrote a successful one recently.
The loop
What happens after you press submit. Including the scary step.
The reason first contributions feel frightening is that nobody describes this part, so it feels like posting an exam to a stranger. It is five steps and one of them is somebody asking you to change something, which is the normal case, not a failure.
You open the pull request
A branch with your change on it, plus a short description of what it fixes and why. This is the part that feels enormous and is actually the smallest.
CI runs
The project's automated tests run against your branch. If they go red, that is information, not judgement — read the log and push another commit.
A maintainer reviews it
Somebody who knows the codebase reads your diff. On a busy project this can take days or weeks, and silence is almost never about you.
Changes requested
The normal case, including for people who do this professionally. It means a human read your work carefully enough to have an opinion about it. You push another commit and the thread continues.
Approved and merged
Your commit is now in the project's history with your name on it, and it stays there. That is the artefact — not a certificate, the commit.
This is the whole loop. Every open-source contribution anybody has ever made went through these five steps, including the ones by people whose names are on the projects.
And the commands, for real
These work today against this website's own repository. The prompts are excluded from what you copy.
your first contribution
# fork it on GitHub first, then:$ git clone https://github.com/<you>/scaleropensourcelabs.com.git$ cd scaleropensourcelabs.com/web$ npm install$ npm run devready on http://localhost:3000# then, for the change itself:$ git checkout -b fix-the-thing$ npm run typecheck$ git commit -am 'Fix the thing'$ git push origin fix-the-thing
We are not checking whether you can already code. We are checking how you think.
Syntax is a few weeks of work. Reading somebody else's codebase and reasoning about it is the part that actually decides whether your first patch gets merged — and it is not what any exam measures. There is no test to pass here and no interview to prepare for. This is simply what the work turns out to reward.
Old way 🚩
✕
A contest rating, or fluency in DSA
✕
Knowing a particular framework already
✕
Prior open-source experience, or any merged work
✕
A tidy GitHub profile with a streak
OSC way 🟢
Reading code you did not write and working out what it does
Turning a vague problem into one small change you can defend
Following a review thread and understanding why a change was refused
Saying "I do not understand this yet" early instead of late
Step 03 is the one.
Show a mentor the patch before a maintainer ever sees it.
LGTM ✅
How a first contribution actually goes
Four steps. The third is the one people skip.
01
Pick a project that needs help
Not the most famous one. A project with open issues, a responsive maintainer, and a test suite that runs on your machine.
02
Find an issue sized for a first attempt
A failing edge case, a documentation gap, a small refactor. Unglamorous work does get merged; that's how you start.
03
Get it reviewed before you send it
Your mentor reads the patch first, so the version a maintainer opens is already close to mergeable.
04
Then do it again
The first contribution is the hard one. Everything after it compounds, because you already know where things live.
The only register here is git log, and it never forgets.
What it's like
It is mostly people arguing about code with Maggi. Which is the point.
01
Discussions, not lectures
Sessions are people arguing about a codebase with a laptop open, not slides. If you have a question halfway through, that is the session.
$ git clone <repo>
# read it first
02
Coffee and Maggi are on the club
Working sessions run late and nobody codes well hungry. There is always chai, coffee and Maggi, and you do not have to ask.
$ git switch -c fix/typo
# small first
03
Work where you like
Library, lab, hostel common room, or the campus spot everyone knows. We pick the location by what the group wants that week, not by what was booked.
$ git commit -m '...'
# say why, not what
04
Nobody is behind
People join knowing wildly different amounts. Sitting in on a session you only half follow is a completely normal way to start, and everyone here did it.
$ gh pr create
# then read the review
Read all four and still here?
Then it is probably for you. That was the whole test.
// TODO: decide
Be honest with yourself
This is not for everyone. Four reasons to walk away now.
Anyone who wants a certificate. There isn't one. The output is a public commit history, which is worth more and photographs worse.
Anyone optimising purely for the DSA round. Go to the competitive programming club — they are better at it — and come here as well if you have the hours.
Anyone who wants to be told exactly what to do each week. You get a mentor and a direction, not a syllabus.
Anyone counting pull requests. Chasing PR count is how Hacktoberfest became something maintainers publicly asked people to stop doing. We are not running that.
Not on the list?
Ask us. If we answer it twice, it ends up here.
ask, don't guess 💬
Questions
The seven things people actually ask.
No. Different skill. Reading an unfamiliar codebase, writing a small correct change and surviving review is what this needs, and none of it is competitive programming.
Four to six once you're going, and more in the weeks around an application deadline. During exams people go quiet and nobody minds — say so and pick it back up.
Yes, and there is nothing to upsell you. The coffee is on the club.
It is a student club at Scaler School of Technology, run by students. Nothing here is a paid programme and nothing here sells you one.
For this year's GSoC cycle, most likely. For LFX Mentorship, no: terms run three times a year and GSoC dropped its student-only requirement in 2022, so graduating does not end your eligibility.
One you can already write and run. Projects exist in Python, Go, Rust, TypeScript, C++ and more; we pick the project around you rather than the other way round.
It will, sometimes. Ours do — 46 of 74 merged on our largest project, which is a normal ratio and the reason we publish it rather than rounding it up.
Applications open
You do not need to be good yet. You need a laptop and a GitHub account.
Most people arrive having never opened a pull request. That is the normal starting point, not a disqualification — every name in the hall of fame began there.