For many new developers, the most intimidating aspect of contributing to an open-source project is realizing that everyone can see your work — but that’s also one of the biggest benefits. 

Showing off your coding chops and sharing technical expertise is how you build a reputation in the developer community, which is important when you’re trying to break into tech. Hiring managers want to see a polished GitHub profile that proves you can write and read code, understand Git, collaborate with other developers, and communicate effectively. 

Docs, our open-contribution coding documentation, lives on GitHub and is a solid entrypoint for anyone interested in contributing to open-source software. From absolute beginners who are grappling with syntax to pro developers with years of experience, Docs is a safe space that devs of all levels can work on and use.

As you write Docs for coding terms and concepts, you’re also giving back to the Codecademy community by sharing your knowledge. A Doc that you contribute could help someone cross the finish line on a coding project or nail a question during a technical interview. 

Taking the leap from scrolling open issues on GitHub to actually clicking the green “create pull request” button can feel nerve-wracking and vulnerable. Ahead we’ll answer common questions that many newcomers have the first time they submit a pull request, so you can feel confident contributing code.

What is a pull request anyways?

A pull request, aka PR, is a request you make to the project maintainers to have them review and (hopefully) merge your changes into the main codebase. In other words, a PR is essentially a way of asking: Can I make a suggestion? 

Making a PR is the last step before your code gets merged into a project’s main codebase. In the free course Learn GitHub: Best Practices, you can learn exactly how to make a clear PR. And when it comes to making a PR on your own, you can always bookmark our step-by-step tutorial (complete with video demos) for how to create a PR in the Docs Contribution Guide.

What makes a “good” pull request?

As a newbie, you might second-guess whether your contribution is significant enough to warrant a change or doubt the value that you’re adding to a project — and that’s totally valid. For starters, make sure you’re choosing the right issue to work on. In GitHub, you can browse issues tagged “good first issue” or “help wanted” to find beginner-friendly open issues. Take a look at what’s tagged a “good first issue” in the Docs repo.

With practice, you’ll get the hang of submitting PRs and won’t stumble through the steps of the process. In general, a good PR:

• Includes a concise and clear description that contextualizes the change
• Contains useful comments and commit messages for the reviewer
• Is small enough to be reviewed and merged quickly

What happens if I mess something up in my code or get rejected? 

No one is going to put you down or judge you if you make a mistake or forget to include a detail in your contribution. Having your code reviewed by someone else (especially a more experienced programmer) for the first time can feel scary, but it’s a huge part of learning and growing as a developer. 

Be open to receiving constructive criticism: The project maintainers will review your proposed changes, and may provide feedback, ask questions, and start discussions about specific lines of code. And while there’s always a possibility that your change isn’t merged, don’t let fear of rejection keep you from trying.

With Docs, the maintainers who review PRs have “collaborator” badges on their profiles. Maintainers look over your code for things like technical accuracy, formatting standards, typos or bugs, and plagiarism. Remember: These are real humans with thoughts and emotions who want you to succeed! 

People in the open-source community are generally welcoming and supportive of beginners, and they understand that contributing is an opportunity for learning and improvement. Not to mention, most folks can remember being in your position and can empathize with impostor syndrome. 

How do I know if my contributions are actually implemented? 

Assuming your changes have been reviewed and approved, a project maintainer will merge your branch into the main codebase. This makes things official: The code you wrote and changes you made are part of the project’s codebase — congrats!

You’ll get credit for any contributions you make, and other folks (like fellow devs and even recruiters) can see you work too. In Docs, for example, you’ll see all the contributors listed at the bottom of the page with links to Codecademy profiles. (Be sure to link your GitHub and Codecademy profiles so you get recognized for your Docs work.) You can add your Docs experience to your resume, or use it as a talking point next time you’re interviewing for a job.