Derzeit ist diese Seite nur auf Englisch verfügbar.
Abstract image for New Relic Blog article

This is part two of a four-part series on getting started with open source projects. Check back for new installments of the series in the following weeks.

Part one of this series discussed five great ways to get started contributing to open source projects. But what makes a great contributor? Honestly, the best contributors are level-headed, great communicators, versatile, and patient.

Keep calm and be kind

One thing to keep in mind when submitting a pull request (PR) is that the project comes first. Is the PR you’re submitting going to help grow the project and add value to users? If the answer is yes, submit the PR. If the answer is no, then think through how you can adjust your PR to add value.

Open source projects allow users to collaborate across communities, which can bring up varied opinions during code review from PRs and issue submissions. If your PR isn’t immediately accepted, don’t fret. Project maintainers, like you, want the project to be valuable for the community.

But what happens when you become a project maintainer? If you’re reviewing a pull request, be constructive and guide the user through the changes. Make sure to comment on potential areas of improvement and encourage the contributor to re-submit their PR after editing. The best part about working in open source is collaboration, so put yourself in their shoes and address your feedback the way you’d want to receive feedback.

Be clear and thoughtful in your writing

As an open source contributor, you’re communicating with the community, so you need your writing to be clear and thoughtful. Use spell-checking and grammar-checks—even if you're a native speaker of the language used in the development community. Read your writing several times, and even read it aloud to make sure it’s articulate and clear. It is quite difficult—especially when dealing with technical concepts—to discern what someone is saying when the contribution is confused by spelling mistakes and poor grammar.

This is relevant in not only your PRs or issue submissions, but also in your READMEs. Having clear, concise, and actionable documentation goes a long way.

Look beyond the code

Sometimes eager contributors jump right into coding and forget that there are other areas of open-source projects that need contributions.

A successful project encompasses many facets beyond code—including UI/UX design, architecture design, documentation, feature planning or public roadmaps, testing, and issue reviews. Contributing to such areas will also give you, as a contributor, a better holistic understanding of the project.

There is no better way to learn the ins and outs of an unfamiliar project than to fix potential issues. Look for a project’s issue board and assign some to yourself. This will give you a good idea of how the project hangs together and put you in a better position to contribute better code further down the road.

Contributing to documentation is another great way to learn about a project and how it works. To document it well, you need to understand it. To understand it, you need to work with it. It’s a cyclical process through which you’ll improve your contributions over time.

Next steps

There are many ways to grow as an open source contributor.

You don’t have to be a developer superhero to become a worthy contributor to a project. Many successful projects have been built on the contributions of every-day developers and even non-developers who are passionate about the work.

You don’t have to be great at any one thing—planning, developing, documenting, or testing—to get started. Greatness is something you can work toward.

Want to contribute to an open source project at New Relic? Check New Relic Open Source and start contributing today.