Every piece of advice about getting into open source says the same thing: browse the
good first issue label, find something small, submit a patch.
I've tried that. Twice. Both times I opened a repository I'd never used, scrolled through issues about code I didn't understand, in a project whose conventions I didn't know, and closed the tab.
My actual first contribution happened by accident, in about forty minutes, and I wasn't looking for it at all.
The wall
I was five days out from a competition deadline, building a WhatsApp agent on Agent Kernel, an open-source agentic framework. Day one, the only thing I needed was a "hello world" round trip — message the number, get a reply.
I copied the setup straight out of the official integration guide.
TypeError.
Now, this is the fork in the road, and I want to be precise about it, because everything downstream came from taking one path instead of the other.
The path I could have taken: try a few variations, find one that works, move on. I had four days left and an entire system to build. Nobody would have blamed me.
The path I took: open the framework's source and find out why.
It cost maybe fifteen minutes. The documentation showed the function being called one way. The actual signature in the source took a different argument shape entirely. The example project in the same repository used the correct form — so the code was right, the example was right, and only the docs were wrong.
I noted it and kept building.
The second one
Two days later I was configuring guardrails, and a field name from the documentation didn't exist on the object.
By then I recognised the shape of it. Straight to the source, found the real field name, noted it, kept building.
Same class of error, same section of the docs, found the same way.
Why documentation bugs matter more than they sound
It's easy to think doc fixes are the participation trophy of open source. Real contributors write features. Everyone else fixes typos.
I don't buy it anymore, and here's why.
Both of these errors were in the integration guide. That's the first page a new user opens. It's the page you follow before you've built any intuition about the framework, at exactly the moment you're deciding whether this project is worth your time.
Every single person starting with that framework hit the same TypeError I did. Some of
them read the source like I eventually did. Some of them tried variations until something
worked. And some of them closed the tab and used something else.
That's not a typo. That's a leak in the top of the funnel.
The maintainers couldn't see it, either — not because they're careless, but because they already know the correct signature. You cannot experience your own documentation as a beginner once you've stopped being one.
That's the thing a new user has that a maintainer doesn't. It expires fast. Use it while you have it.
How I actually filed it
The mechanics matter, especially the first bit, which is where I'd have gone wrong without thinking about it.
Branch from upstream, not from your own work. My fork already had days of competition code on it. If I'd branched from where I was standing, my pull request would have carried all of that with it.
git remote add upstream https://github.com/yaalalabs/agent-kernel.git
git fetch upstream
git checkout -b docs/fix-api-signatures upstream/develop
Check the base branch. Their default is develop, not main. A PR against the wrong
base gets closed and reopened, and you look like you didn't read anything.
One commit per fix, in whatever commit format the project uses. Theirs is conventional commits, so:
git commit -m "docs: correct RESTAPI.run signature in WhatsApp integration guide"
Verify your diff before pushing.
git diff upstream/develop --stat
Two files. Exactly the two I meant to touch. This one command is what stands between a clean PR and accidentally proposing your entire side project to someone else's repository.
Cite the source of truth in the PR body. For each fix, the file and line of the documentation, and the file and line of the actual code that proves it's wrong. A reviewer who doesn't have to go verify your claim merges faster.
Batch related fixes into one PR. Two commits, one pull request. Filing them separately would have doubled the review overhead for the same amount of value — and in a project running a community engagement prize at the time, trickling out separate PRs would have looked like farming rather than helping.
It was reviewed and merged.
What made it work
Not skill. I'm a third-year IT undergraduate and I did not write a line of the framework's actual code.
What made it work was being a real user with a real problem, and choosing to understand the failure instead of routing around it.
That's the whole loop:
- Use the project for something you actually need
- Hit a wall
- Read the source to understand the wall — don't just work around it
- Notice when reality disagrees with the docs
- File it
Step 3 is the only step people skip, and it's the one that generates everything else.
If you're looking for your first contribution
Stop browsing issue labels. Go build something you actually want to exist, using a tool you haven't used before, and pay attention to every moment you get confused.
Those moments are the contributions. A confusing error message, a missing prerequisite in a setup guide, an example that doesn't run, a signature that changed and left the docs behind. You'll find several. Most people just push through them and forget.
Newer projects are the richest ground for this, because their documentation hasn't been through thousands of pairs of eyes yet. And smaller projects tend to review faster and respond like humans.
You don't need to be qualified. You need to be the person who got stuck and wrote down why.
This happened while building a maternal health agent for the IDEALIZE 2026 mini-competition. The build itself — and why most of it was about deciding what the AI wasn't allowed to do — is a separate post.