Focus

Pick a small number of Open Source communities to be a part of and make a real contribution. That’s way better than joining a lot of communities and not helping.

One Maintainer: “And remember everyone, while you can belong to multiple communities, I don’t recommend joining 100. I highly recommend joining two or three because you get different things from different communities. But don’t try and join 10 or 20, or 30, it just doesn’t work. It’s not beneficial to the community, and it’s not beneficial to yourself.”

‍

Read the documentation

Maintainers are doing their best to build documentation to make it easier to be an effective Contributor from the start. A quick way to earn trust is to read that documentation before asking a question. Maintainers are so busy that it is much better for them to work on things that help the many, not the one– and documentation is a great example.

Pro tip: Particularly like the documentation? Say thank you to the Maintainer(s), and explain why. It is always the right time to give a specific, positive, compliment.

‍

Learn in public

Learning in public means asking your questions to many people rather than one, privately.

The benefit for the Community is that your question might help other Contributors. And it saves time for the busy Maintainers, by letting them help many people at once.

Another Maintainer: “If you ask me a question, I’m going to have the same conversation with the next person. And so when you comment publicly, you’re literally helping those people as well. That’s why it’s so important to ask in public. It’s not just for you, but maybe 100 other individuals that are literally faced with the exact same problem. I guarantee you, if you’re having a problem, someone else has had the exact same problem. And by commenting about it publicly, you’re helping everyone.

“That’s why Stack Overflow exists. Do you think it exists for that one person’s problem that nobody else needs? No, we all find that same question to answer because we have the same problem. It’s the same exact concept here. Trust me on this.”

Pro tip: worried that your question might be too silly, or obvious, and you’re concerned how you might look? Ask it in public anyway and see what happens.

If members of this community are disrespectful, well, you have learned something valuable about their values– and it’s likely time to find a new community. I promise there are many great Open Source communities out there that would be thrilled to have your help and have you ask questions in public.

‍

Pick a community that is welcoming to new Contributors

Some Communities are better set up for newcomers. If you are just getting started, it makes a lot more sense to start with a community that is prepared to help you have a great experience.

Of course, I highly recommend EddieHub as one such community.

Other ways to tell? Go to another community and just jump in and start approving pull requests and asking random questions.

OK… that was a test to see if you read the previous sections. Never do that. ;0

The other ways to tell if an Open Source community is set up for newcomers is to read the Documentation, to see how understandable they are, and the issue list, to see if stories are clearly indicated that they are suitable for newcomers. If you love the topic of the code but it’s not clear how you can help, start helping somewhere else and then come back when you are more ready.

There are many exceptions, but in general, I recommend the Goldilocks rule. Beginner-friendly projects are likely not too big (like React) or too small (with only one Maintainer and a few contributors), but have a “just right” level of Contributors and Maintainers.

Pro tip: I recommend watching a community for at least a week to understand the flow of contributions and conversations — after you’ve read all the documentation — before you try to contribute. You want to start off on the right foot.

‍

If you are contributing code, create small pull requests

Each version control system (GitHub, GitLab, Bitbucket) uses different terminology for code reviews. For example, in GitHub, coders create a pull request once their code is ready for review. They may also identify one or more people to review the code, or a manager could select people to serve as code reviewers, or anyone can volunteer.

A code reviewer leaves feedback either for the pull request as a whole, or individually through comments. A single pull request can have 1–100+ code review comments but less is definitely more here.

It’s highly recommended to create pull requests small enough to only need 1–3 comments. This makes it easier for the Community and reduces the likelihood of blockers.

Another Maintainer: “As a maintainer, if you get a large pull request, is a lot of work. And larger pull requests do often get resulted in getting reviewed later, and maybe by fewer people. And that way, they end up with more conflicts, and it takes longer for them to get merged in.

“It’s really OK to think, ‘actually, I don’t have to add more lines to this pull request. If it’s two lines, but it adds value, then perfect. That can that can get merged in and then some other features and changes and fixes and improvements can all come in another pull request.”

‍

Remember there are more ways to help than just coding or code reviewing

I know when I started getting involved in Open Source, I thought it was only about contributing code.

But then I realized it can be so much more than that.

Here are some Maintainers’ tips on ways you can help that aren’t coding:

“But I think the easiest way to support people is if you see a question on any platform, answer it. Or even if you can’t answer it, point the person to someone who can answer it.”

“Just being available to other people is a great way of supporting it can be answering questions, it could be pointing out resources, it could be connecting others to each other as the small way of supporting people.”

“Documentation is a great way to help. There’s so much documentation and it’s so helpful to get help with keeping it up to date. It’s even helpful to volunteer to translate documentation into multiple languages.”

‍

Just make sure you are actually helping

There are many reasons you might choose to help with an Open Source community– for learning, for career advancement, to give back. Any of those reasons, and others, are good ones.

But you owe it to the community you are a part of to make sure your work is actually useful. Much better to make a smaller number of contributions that matter (see Focus, above) than spread yourself too thin.

And especially please avoid contributing for contributing’s sake– not only does it not help the community, but it can slow them down. And it doesn’t serve you well either.

Again, the Maintainer point of view: “One thing I’ll just caution people is don’t just try and make activity on your profile, because it creates a lot of noise for everyone else in the project and the maintainers. Writing “great” on everything, without even actually reviewing it, actually has a negative effect for your own GitHub profile, and the community as well. So just make sure what you’re doing is adding value.”

“Please don’t go approve a pull request that’s already been merged. It makes absolutely no sense. You’re adding value there. It’s merged. It’s been approved enough to get merged. And it just creates noise, not only for the maintainers. But for everybody involved in that discussion.”

Pro tip 1: spending a week watching the community before you try to contribute is a good way to calibrate what’s really helpful.

Pro tip 2: imagine one of the Maintainers is standing in front of you and you are explaining the contribution you made. Can you look that person in the eye and explain why your contribution is good for the community, and not just an activity metric for you? If yes, great. If not, find a better way have.