Taken from: https://opensource.guide/

You don’t have to contribute code A common misconception about contributing to open source is that you need to contribute code. In fact, it’s often the other parts of a project that are most neglected or overlooked. You’ll do the project a huge favor by offering to pitch in with these types of contributions!

Anatomy of an open source project

Every open source community is different.

A typical open source project has the following types of people:

• Author: The person/s or organization that created the project
• Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)
• Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project. (They may also be authors or owners of the project.)
• Contributors: Everyone who has contributed something back to the project.
• Community Members: People who use the project. They might be active in conversations or express their opinion on the project’s direction.

A project also has documentation. These files are usually listed in the top level of a repository.

• LICENSE: By definition, every open source project must have an open source license. If the project does not have a license, it is not open source.
• README: The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
• CONTRIBUTING: Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
• CODE_OF_CONDUCT: The code of conduct sets ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
• Other documentation: There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.

Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.

• Issue tracker: Where people discuss issues related to the project.
• Pull requests: Where people discuss and review changes that are in progress.
• Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, “How do I…“ or “What do you think about…“ instead of bug reports or feature requests). Others use the issue tracker for all conversations.
• Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.

Finding a project to contribute to

Start by thinking about the projects you already use, or want to use. The projects you’ll actively contribute to are the ones you find yourself coming back to.

Maybe you noticed something is broken, or there's an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That’s what open source is all about!

You can also use one of the following resources to help you discover and contribute to new projects:

• GitHub Explore
• Open Source Friday
• First Timers Only
• Your First PR
• CodeTriage
• 24 Pull Requests
• Up For Grabs
• Contributor-ninja

Things to check before contributing

Checklist:

Check that the project actively accepts contributions Commits: When was the latest commit? How often do people commit?

Issues: How many open issues are there? Do maintainers respond quickly to issues when they are opened? Are the issues recent? Are issues getting closed?

Pull requests: How many open pull requests are there? Are the pull requests recent? Do maintainers respond quickly to pull requests when they are opened?

How to submit a contribution

You’ve found a project you like, and you’re ready to make a contribution. Finally! Here’s how to get your contribution in the right way.

Opening a pull request You should usually open a pull request in the following situations:

• Submit trivial fixes (for example, a typo, a broken link or an obvious error)
• Start work on a contribution that was already asked for, or that you’ve already discussed, in an issue

If the project is on GitHub, here’s how to submit a pull request:

• Fork the repository and clone it locally. Connect your local to the original “upstream” repository by adding it as a remote. Pull in changes from “upstream” often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions here.)
• Create a branch for your edits.
• Reference any relevant issues or supporting documentation in your PR (for example, “Closes #37.”)
• Include screenshots of the before and after if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
• Test your changes! Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don’t break the existing project.
• Contribute in the style of the project to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.

What if:

You don’t get a response. Don’t reach out to people privately; remember that public communication is vital to open source projects.

If you make a polite bump and still nobody responds, it’s possible that nobody will respond, ever. It’s not a great feeling, but don’t let that discourage you. It’s happened to everyone! 

Someone requests changes to your contribution. It’s common that you’ll be asked to make changes to your contribution, whether that’s feedback on the scope of your idea, or changes to your code. When someone requests changes, be responsive

If you don’t have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they’re not expecting a response. Someone else may be happy to take over.

Your contribution doesn’t get accepted. Your contribution may or may not be accepted in the end.
You’re always welcome to fork and work on your own version.