Do you like to code?

Find an open issue to tackle

Ask if you can help write a new feature

Automate project setup

Improve tooling and testing

Do you like helping others code?

Review code on other peoples submissions

Write tutorials for how a project can be used

Offer to mentor another contributor

You dont have to contribute code

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

Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project.

Do you like to design?

Restructure layouts to improve the projects usability

Conduct user research to reorganize and refine the projects navigation or menus,

Put together a style guide to help the project have a consistent visual design

Create art for t-shirts or a new logo,

Do you like to write?

Write and improve the projects documentation

Curate a folder of examples showing how the project is used

Start a newsletter for the project, or curate highlights from the mailing list

Write tutorials for the project

Write a translation for the projects documentation

Every open source community is different. Spending years on one open source project means youve gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different. That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.

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 projects direction



Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a projects website for a “team” page, or in the repository for governance documentation, to find this information.

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. A good example of an effective Contributing Guide would be the one from Codecademys Docs repository.
• 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 like Astro Docs.

Finally, open source projects use the following tools to organize discussion:

Issue tracker: Where people discuss issues related to the project.

Pull requests: Where people discuss and review changes that are in progress whether its to improve a contributors line of code, grammar usage, use of images, etc. Some projects, such as MDN Web Docs, use certain GitHub Action flows to automate and quicken their code reviews.

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.

Communicating effectively

Whether youre a one-time contributor or trying to join a community, working with others is one of the most important skills youll develop in open source. Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.

• Give context. Help others get quickly up to speed. If youre running into an error, explain what youre trying to do and how to reproduce it. If youre suggesting a new idea, explain why you think itd be useful to the project (not just to you!).
• Do your homework beforehand.Its OK not to know things, but show that you tried. Before asking for help, be sure to check a projects README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that youre trying to learn.
• Keep requests short and direct.Much like sending an email, every contribution, no matter how simple or helpful, requires someone elses review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
• Respect community decisions.Your ideas may differ from the communitys priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.

Gathering context

Before doing anything, do a quick check to make sure your idea hasn’t been discussed elsewhere. Skim the project’s README, issues (open and closed), mailing list, and Stack Overflow. You don’t have to spend hours going through everything, but a quick search for a few key terms goes a long way.

If you can’t find your idea elsewhere, you’re ready to make a move. If the project is on GitHub, you’ll likely communicate by doing the following:

• Raising an Issue: These are like starting a conversation or discussion
• Pull requests are for starting work on a solution.
• Communication Channels: If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution.

Opening an issue

You should usually open an issue in the following situations:

• Report an error you can’t solve yourself
• Discuss a high-level topic or idea (for example, community, vision or policies)
• Propose a new feature or other project idea

Tips for communicating on issues:


• If you see an open issue that you want to tackle, comment on the issue to let people know you’re on it. That way, people are less likely to duplicate your work.
• If an issue was opened a while ago, it’s possible that it’s being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
• If you opened an issue, but figured out the answer later on your own, comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.

Opening 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. It’s important to 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.

😭 You don’t get a response

Hopefully you checked the project for signs of activity before making a contribution. Even on an active project, however, it’s possible that your contribution won’t get a response.

If you haven’t gotten a response in over a week, it’s fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread.

Don’t reach out to that person privately; remember that public communication is vital to open source projects.

If you give a polite reminder and still do not receive a response, it’s possible that nobody will ever respond. It’s not a great feeling, but don’t let that discourage you! 😄 There are many possible reasons why you didn’t get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive.

🚧 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. They’ve taken the time to review your contribution. Opening a PR and walking away is bad form. If you don’t know how to make changes, research the problem, then ask for help if you need it. A good example of this would be the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy’s Docs.

If you don’t have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you’re unable to find a solution, let the maintainer know so that they can open the issue for someone else, like @RitaDee did for an issue at OpenSauced’s app repository.

👎 Your contribution doesn’t get accepted

Your contribution may or may not be accepted in the end. Hopefully you didn’t put too much work into it already. If you’re not sure why it wasn’t accepted, it’s perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you’ll need to respect that this is their decision. Don’t argue or get hostile. You’re always welcome to fork and work on your own version if you disagree!

🎉 Your contribution gets accepted

Hooray! You’ve successfully made an open source contribution!