Once you’ve identified an area where you can contribute, the next step is to prepare your contribution.
Here, we’ll review how you can communicate your intent to participate in a project, create a pull request, and increase your chances of having it accepted.

When it comes to contributing to an open source project, communication is a key factor for success.
You may feel uncomfortable discussing the changes or improvements you’re proposing with others.
Often, this dialogue will lead to discussions and compromises on your initial idea.

Avoiding active communication with others involved in an open source project means you risk spending time working on tasks that someone else is already doing.
Or you might work on features or improvements that don’t align with the project’s values or best practices.
In both cases, everyone’s time is wasted.
On the other hand, engaging in active communication ensures that your work will be well received and impactful.

How to Ensure Successful Communication with Project Members About New Features or Changes
Start by keeping an open mind.
Be receptive to feedback and patient.
Open source project maintainers most likely have full-time jobs and personal lives to manage.
If you don’t receive a response immediately, wait a bit longer before following up with the maintainers.

Communicate Your Intent to Maintainers
You should always start by expressing your intent to contribute before beginning work.
Unless otherwise stated in the README file, the issue tracker is usually the best place to do this.

If you want to work on an existing issue, check that no one is already assigned to it by looking at the Assignees section.
Also check the Linked pull requests section.
A linked pull request means someone is already working on it.
Browse the comments to see if anyone has expressed interest in the issue.
If everything is clear, post a comment on the issue to indicate your intent to take it on.
This way, you inform others interested in the issue that someone is already working on it.
Additionally, if needed, maintainers can reply with guidance and direction.

Contributing a New Feature or Fixing a Bug
If you want to work on a new feature or a bug that isn’t yet listed in the issue tracker, create a new issue.
Make sure to follow the provided template if there is one, and clearly express your intent to work on the issue.
If it’s a feature proposal or the issue requires significant changes, be sure to get approval from the maintainers before moving to the next step.

Creating a Pull Request on a GitHub Repository
Once you’ve communicated your intent to help with the project, you’re ready to start working on your contribution.

Your contribution will take the form of a pull request (or PR).
A pull request is a special space on GitHub that includes several elements:

• A title and description of your changes.
• One or more commits that make up the changes you’re proposing.
• Comments, where anyone can join the discussion about the changes.
• Code reviews, where you can receive detailed feedback on your changes and possibly suggestions for improvements.
• Status checks, such as automated tests set up by the maintainers. These checks may serve different purposes: ensuring your changes follow the project’s rules or verifying that they don’t break existing code.

Once the pull request is created, it can be updated with new commits, comments, or code reviews.
This process continues until the project maintainers approve and merge the pull request, or reject the changes and close it.
When your pull request is merged, it means your changes have been integrated into the project’s codebase.

Step-by-Step: Creating a Pull Request

1. Open the GitHub page of the project you want to contribute to.
2. Click the Fork button to create a copy of the repository on your GitHub account.
   This step is necessary because, by default, you don’t have permission to modify a public repository unless it’s your own copy.
   By forking the project, you create a copy where you can make changes.

3. Select Your repositories from your account’s profile menu.

4. Select the fork of the repository.
5. Click the Code button to get information on how to clone the Git repository to your local machine.

Select the clipboard icon to copy the repository URL, then enter this into a terminal:

git clone <REPOSITORY_URL>

git clone <REPOSITORY_URL>

This command will create a copy of the repository on your local machine.

Alternatively, you can use GitHub Desktop if you prefer working with an application.
Or you can use GitHub Codespaces if that option is available to you.
If you’re a Visual Studio Code user, GitHub Codespaces will feel familiar.

7. Once the project is cloned, navigate into the project folder:

cd <PROJECT_FOLDER>

cd <PROJECT_FOLDER>

(Optional) Create a new branch using the following command:

git checkout -b <BRANCH_NAME>

git checkout -b <BRANCH_NAME>

This step is not mandatory, but it is highly recommended.
With a new branch, you can work on multiple contributions separately, each on a different branch.

Make the desired changes to the project and commit them:

git add .
git commit -m "<COMMIT_MESSAGE>"

git add .
git commit -m "<COMMIT_MESSAGE>"

This step is not mandatory, but it is highly recommended.
With a new branch, you can work on multiple contributions separately, each on a different branch.

Make the desired changes to the project and commit them:

git push --set-upstream origin <BRANCH_NAME>

git push --set-upstream origin <BRANCH_NAME>

This command creates a new branch on the remote repository on GitHub (your fork), and pushes all your commits to it.

If you haven’t created a branch beforehand, simply enter:

Then, open the fork of your project on GitHub and click the “Compare & pull request” button in the suggestion box that appears.

Fill in the title and description, then select Create pull request.

If there is a template for the pull request description, take the time to fill in all the requested information.
If there isn’t one, make sure to provide enough context so that maintainers understand the changes you’re proposing and why.

You should also link to the related issue by mentioning its number using #<ISSUE_NUMBER>.
You can find the issue number next to its title.

Passing Status Checks

After creating the pull request, you may see a section with status checks at the bottom, like this:

These status checks are automated tests set up by the maintainers to ensure consistent project quality.

For your pull request to be accepted, it must pass all automated checks.
If one of them fails, as shown in the previous screenshot, click the Details button to learn more about the failure and find out what you need to do to fix it.

If you’re not sure what to do about a failed check, you can always use the comments to ask the maintainers for advice or help.

Requesting Feedback or Reviews on Pull Requests

You may have doubts about some of the changes you’ve made and want feedback from the maintainers.
The best way to do this is to comment directly in the pull request.
If you consider your changes to be a work in progress, you also have the option to create a draft pull request to ask for guidance or help from other contributors.

After the project maintainers review your pull request, they may respond to the conversation or directly review your changes. Several outcomes are possible following a pull request review:

• Your changes are approved. Congratulations!
• Your pull request requires changes. Don’t be discouraged! Carefully review the feedback provided. If you make the requested changes, there’s a good chance your pull request will be accepted. If you push new commits to your branch, the pull request will automatically update with the new changes.
• The reviewer has left comments. This usually means more details are needed about your changes or the reasoning behind them.

Responding to Comments on Your Pull Request
Always remember to remain respectful in all your interactions and follow the code of conduct.
It’s likely that before your changes are accepted, an ongoing discussion will take place with maintainers or other contributors.

Contributing to open source requires patience. Sometimes, you won’t receive immediate feedback.
Do not try to contact maintainers privately via email, X (formerly Twitter), or any other means in hopes of getting a faster response.
This behavior is considered harmful.

Public discussions also allow other contributors or visitors to learn about the process behind the changes and the best practices to follow.