I created my first open source pull request (PR) on October 11. When I saw the automated tests transition one-by-one from processing to passed, I was already hooked. The notification came through a few hours later that my PR had been approved and merged, and it was official: I wanted to contribute to more projects, learn new languages, and master every new-to-me developer productivity tool under the sun.
A classmate had recently completed a '100 Days of Code' challenge. I'd considered doing something similar, but hadn't come up with a good focus. After that first PR merge, I found my focus: create 100 non-trivial pull requests in 100 days.
(Why specify 'non-trivial'? It's surprisingly easy to automate PRs that correct common typos or formatting errors without ever even cloning the repository. I was determined that each PR in my challenge would require me to build and use a local development environment.)
I'm almost 20 days into my challenge. I've created 30 pull requests in 29 repositories, and 26 of them have been approved and merged. (3 are awaiting review and 1 was rejected.) The projects I've contributed to range from personal portfolios and practice projects, to large open-source apps and chrome extensions used by millions of people.
Here are some things I've learned:
100 PRs in 100 days is a breakneck pace
It limits contributions to relatively easy tasks, like hunting down a small UI bug or adjusting CSS breakpoints to make a layout more responsive. Harder tasks like refactoring take a few days. I'm OK with my contributions being relatively minor in this challenge, because I'm going for breadth at this stage instead of depth.
Everything breaks, all the time
If a project has contributing guidelines that outline how to set up your local development environment, follow them TO THE LETTER. You never know when completing steps in an order that shouldn't break the setup process in theory will, in practice, break the setup process. Guides about setting environment variables should be read very closely.
Contributors are flaky
I've seen so many issues that have been claimed and then abandoned. The issue owner will check in with the assignee and get no response, then eventually un-assign it. A few days later someone new will come along asking to be assigned, and the same process will start again. Best practice is to write a note to set expectations on timeline and blockers. If solving the issue will involve multiple commits, it might also be a good idea to create a draft pull request after the first commit so that its public knowledge that progress is being made.
Reviewers are flaky too
It took 8 days for my simple formatting changes in O3DE to be reviewed. I'm still waiting (15 days and counting) for an answer & assignment on a Public Labs project. I've learned to not be too upset with radio silence - I just move on and appreciate the experience.
Every community is different
Some projects have no contributing guidelines but expect you to know & follow a strict community code. Others have delightfully extensive guides to help onboard new contributors. Repositories sometimes have strict PR templates that must be followed to the letter; almost all projects require commits to be signed off on (thankfully there is a setting in VSCode that makes that automatic.) Becoming familiar with & following multiple of these divergent community rules each week is a bigger challenge than I'd anticipated.
Contributing is incredibly rewarding
In just a few weeks, I've had the opportunity to practice so many parts of what the onboarding process will entail at a new job - setting up the environment, learning the codebase, working with new people, finding issues & tickets that are challenging enough to teach you something new, but not so challenging that you'll delay others taking too long to complete them. I am grateful every day that I've found a way to practice these skills. If I can contribute 100 PRs in 100 days, I can certainly get fully up to speed on 1 project in the same time frame.
TL;DR
Creating 100 pull requests in 100 days as a SWE-in-training is far tougher than I expected. I'm not certain the format is ideal, either - the time spent in any one repository feels so fleeting. I thought many times about altering the challenge, but ultimately the only change I made was allowing myself two PRs against the same repository (if the issues were significantly different or exceptionally complex for my skill level.)
The thing is, a challenge is supposed to be difficult. If it's easy, it's not a challenge. And I'm still in the early stages, feeling just as overwhelmed as I was in the first couple weeks of learning JavaScript, R, or C. The beauty of a challenge like this is that it turns something that seems difficult and insurmountable into a regular routine.
I can't wait to see where it takes me.
Top comments (0)