I recently finished an open source challenge where I contributed 100 Pull Requests to open source projects in 100 Days. I cannot recommend this style of challenge enough!
My experience level fast-forwarded so much from the challenge, I worked with dozens of new languages and tech stacks on real-life projects, and it was easier to see the commonalities across them because I was working on them in such a short period of time. I became confident in making contributions even when I felt I didn't know the language or framework well enough, while also staying constantly aware of just how much I don't know yet about coding.
I've been struggling to figure the most helpful way to share what I learned, but one of the questions I'm most often asked is: "what steps did you take to go from issue to completed PR?"
This post outlines the steps in that process. I'll add additional posts for each of them over time, with more detailed explanations. (For background on the terminology, see this previous post on what to know before you start.)
The Five Steps
In general, each pull request you do will to follow the same 5 step process:
- Search GitHub issues to identify potential issues to help address
- Read the contributing guidelines and eliminate any repositories with too many or too few contributing guidelines
- Build your local development environment and eliminate issues where you're unable to build the environment after three tries
- Do the work (write the code)
- Submit your work (open the pull request)
And of course Step 6 (usually after some back & forth with the issue owner about changes to your code): celebrate your PR being merged!
Each time, you start with many potential issues and narrow them down as you go along, so that only the ones you're most likely to be able to help on are your "to do" list for the day.
Step 1: Search the issues
GitHub lets you search all issues across all repositories. Rather than try to find repositories first and then look for issues in them, it's easier to start by searching open issues. My go-to search is is:open is:issue archived:false no:assignee label:bug,"good first issue","help wanted" , followed by a keyword related to what type of work I'd like to do that day (i.e. react or responsive or logic.) It looks for open issues without an assignee (i.e. no one is publicly working on it yet) that have labels that indicate they're good for junior or first-time contributors.
Your goal in looking through the results is to find 5-10 issues that:
- have clear and detailed descriptions
- have keywords that you're familiar with
- are narrow in scope
- are less than 6 months old
- have no pull requests open against them yet (the branch icon in the screenshot below indicates that a pull request has already been opened for the issue)
You should also avoid issues that are only a few days old. Many repos allow anyone to submit an issue. The project maintainers usually need time to validate new issues - you don't want to start working on a 'bug' that turns out to be a feature!
Step 2: Read the contributing guidelines
Now that you've identified some issues, you've still got vetting to do. Read the contribution guidelines and make sure you can participate without jumping through too many hoops. Some repositories are only looking for long-term contributors and want you to email them beforehand, get set up with a mentor, have regular meetings, etc. Those projects are not a good fit for this challenge -
your goal is breadth of experience, not depth.
Other projects might have zero instructions on how to contribute or set up the project locally for development - that's also not ideal.
You might find that you drop drop about 2 out of every 3 'promising' issues at this stage.
Step 3: Build your local development environment
Once you've found an issue you can contribute to, you'll need to:
- Fork the repository
- Clone the forked repository to your local machine
- Follow the repository's directions for building your local development environment.
This is another step where you'll cut a lot of issues from your list - if you can't build the development environment after three tries, move on to the next issue. Over time, you'll learn to recognize and navigate around common issues in this step. But at the start, focus your efforts on projects where the dev environment build is successful within the first few tries. Clear instructions in the repository help a lot with this step.
If you are studying a specific stack, building environments for that stack will be the easiest for you. Start with what you know, but branch out into trying new stacks when you feel a little more confident.
Step 4: Do the work
Once you have a working local development environment, you can start to explore the repository and try to identify where the issue is coming from. If you're lucky, the person who posted the issue explained where to find it in the code. If not, you'll have to do some searching to narrow it down. Remember that GitHub has an option to search the whole repository for a word, and VSCode has the option to search all files as well.
Before you make changes, checkout a new branch in git. If there's no branch naming rules in the contributing guide, you can look at past pull requests in the repo to see whether there is an unwritten rule that people are following.
Step 5: Submit the work
When you think you've solved the issue, take a last pass through your code. Remove any console.logs, TODO's, and unused variables. You want to deliver something clean and readable! Run the repo's preferred linter to make sure you've formatted your code the right way, and make sure it passes any tests that are available for you to run.
Push your changes to your fork on GitHub and navigate to that repository in your browser. If your push was successful, you'll see a notification that has an option to open a pull request.
Once you click on the 'compare & pull request' button, you'll see fields to add a title and some descriptive content. Many repositories have templates or specific formats - follow these if they exist! If not, be succinct in your post but try to keep a friendly tone. (This is the issue owner's first time meeting you!)
Once you're satisfied with your title and comments, click the 'Create pull request' button to open your pull request.
Success!
That's it - you've opened your pull request! Give yourself a pat on the back that you've completed the five steps and have made a contribution!
This process was what I used every day to determine which issues I'd work on during the challenge. Let me know if you've found a different approach that works for you!
One thing to keep in mind: Since issues are constantly changing and being assigned, addressed, or closed out, if you embark on this challenge you'll want to get into a flow of doing these steps regularly. You can't, for example, identify an issue on a Monday and trust that it will still be in the same 'available for me to work on' state on Thursday.
In the follow up posts over the next few weeks, I'll go over each of these steps in a little more detail - thanks for reading and I hope this helps guide you on your journey!
Top comments (1)
I can’t thank you enough - I’ve been wanting to start contributing for some time, but have remained overwhelmed by the possible complexities. You detailing your experience has helped me see how doable it actually is. I know I’m going to gain so much from the challenges I’ll encounter so, again, THANK YOU!