October was a busy month. I set out to make useful contributions across a few repos and ended the month with four pulled PRs. Below is a short, friendly summary of what I did each week, how I work, what I learned, and just my thoughts on the whole process.
What I worked on:
- NIRMAAN: it was my first contribution and it was a simple and quick task to compose a README.
- vscode-pets: it was my second cintribution and I added a setting so users can pick the ball color to throw from VS Code Settings instead of being prompted every time.
- physicshub.github.io: I fixed a visual bug where a canvas would slowly shift color when a “trail” effect was toggled.
- vscode-pets: I worked on this repo again and there was an isuue to add a new feature so additional pets you spawn don’t vanish when you switch folders.
Before I started coding, I spent a lot of time searching for repos and issues that were a good fit. That part turned out to be the hardest. I’d find a project that looked perfect: right language, interesting project, open issues, and then spend hours trying to implement something only to realize I can't really work on it.
One example of that: I spent a whole day poking at the hediet/vscode-drawio extension because I really liked and and I use drawio a lot for schoolwork, so it looked like a great place to contribute. The repo embeds the draw.io project and many parts are tightly coupled to that upstream code. I picked a change that I thought was safe to make inside the extension, but after digging deeper I discovered the behavior I wanted actually required changing drawio itself. That was frustrating as I’d spent time understanding the repo only to have to abandon my attempt. I feel like finding the right repo and the right issue is a skill. I think and hope with more time and exposure to open source I’ll get better at spotting good matches faster.
Another important thing I learned by mistakes is the story of my first PR at the vscode-pets project . At first everything looked straightforward: I forked the repo, implemented the feature, opened a PR, received feedback, addressed the feedback, and pushed another commit. Then the maintainers tried to merge my changes and the merge failed because the CI lint check didn’t pass. The repo’s contributing guide explicitly asks contributors to run npm run lint and npm run lint:fix before submitting, which I did, but apparently not carefully enough. The lint failure blocked merging. When I went back to fix the lint errors, I also discovered my branch was behind the upstream main. That’s normal and easy to fix, but things went sideways and then force-pushed. The force-push replaced the branch history on the remote and my earlier commits disappeared from the PR, leaving a single commit instead of the sequence I intended. I panicked for a bit because I didn’t fully understand what had happened, but the branch was only locally inconsistent, the commits still existed in my reflog. To recover I used Git diagnostics and repair tools. I inspected the history with git reflog and git log to find the SHAs of my lost commits, created a safety backup branch, then reconstructed the branch history by resetting to the correct base commit and cherry-picking the missing commits back in the intended order. Overall the history under the PR became a bit messier than I originally wanted, but recovering those commits myself taught me more about Git than any tutorial could. It was stressful in the moment, but I now feel more confident.
All my other contributions went pretty smoothly, and despite the hiccups I genuinely learned a lot through trial and error. I was pleasantly surprised by how helpful and collaborative the open-source community is, for some reason I expected things to be more hostile. It is vey fun to be in the community where your work is very welcome. Most maintainers and contributors were patient, left constructive feedback, and gave useful pointers that made my changes better. That made the whole process feel welcoming and encouraged me to keep improving my work.
Top comments (0)