How to Contribute to Open Source.
I'm developer from Bangladesh.
In this chapter, I'll guide you through the process of contributing to open-source projects.
Finding a Project to Work on.
One of the first challenges you might face when getting started with open-source is finding a project to contribute to. Here are some tips to help you discover projects that align with your interests and skills.
Browse GitHub and GitLab: Both GitHub and GitLab host a vast number of open-source projects. You can use their search functionality to find projects based on specific keywords, programming languages, or topics.
Follow your interests: Think about the tools, frameworks, and libraries you use or are interested in learning more about. Many of these projects are open source and welcome contributions from the community.
Join open-source communities: There are numerous online communities, forums, and chat platforms dedicated to open-source development. By joining these communities, you can connect with other developers, discover new projects, and find collaboration opportunities.
for example, https://goodfirstissue.dev/, this website is good for beginners to start contributing to open-source.
OpenSouced is another platform you can contribute to and using a Search engine like Google you can find open-source projects too.
Onboarding in a New Project.
When you're interested in contributing to a new open-source project, it's important to familiarize yourself with the project's guidelines, conventions, and workflow and take the initiative to onboard yourself.
Here are some tips to help you onboard successfully:
Read the project's documentation: Read the README file, contributing guidelines, and code of conduct to familiarize yourself with the project. They'll help you understand the project's goal, requirements, and expectations for contributors.
Start Small: When you're new to a project, it's a good idea to start with small, manageable tasks, such as fixing bugs, adding tests, or updating documentation. This will help you become familiar with the codebase and development workflow without getting overwhelmed.
Join the community: Many open-source projects have online communities, forums, or chat platforms where developers can ask questions, share knowledge, and collaborate. By joining these communities you can connect with other contributors, learn from their experiences, and get help with any issues you encounter.
Ask for help: If you need clarification or encounter a problem, don't hesitate to ask for help. Open-source communities are generally supportive and welcoming; other contributors will gladly assist you.
Be patient and persistent: Onboarding in a new project can be challenging, especially if you're new to open-source development. Be patient, and don't be discouraged by setbacks or mistakes. You'll become more comfortable and confident in your contributions with persistence and practice.
Getting Started With Contributing
So, you've onboarded yourself in the project. Now, you can prepare to contribute by following steps:
1. Read the Documentation
We touched on this briefly in the previous section. But it's worth revisiting because it's important to read the project's documentation thoroughly before you start contributing.
Start by reading the README and familiarize yourself with the project. A README contains an introduction to the project, such as how it works, its purpose, the tech stacks it uses, and how to set up and run the local environment.
Once you're familiar with the project and interested in contributing, don't jump in without reading the contributing guidelines. These rules are written in the contributing guidelines, which contain information on how to claim and work with issues, create pull requests, and preferable methods of communication. For example, you can look at the OpenSauced Contributing Guidelines.
Some projects also have conventions, such as code and Markdown style, how to write commit messages, pull requests and issue titles, and so on. You might find these in their style guide or contributing guidelines.
Read the contributing guidelines carefully to understand how the project receives contributions. Following these guidelines will make your contribution process smoother.
2. Find or Create an Issue
After reading the documentation, you can start looking for issues labeled as "good first issue, or "beginner-friendly" that are suitable for you skill label. When choosing which issues to work on, consider your interest, skill level, and available time.
Issues can be seen as proposals for changes. Suppose you want to report a bug or have ideas for a feature or improvement of the project or its documentation and want to propose them. In that case, you can create an issue to propose you intention.
Read this blog post to learn how to fill in issue forms.
In open-source, it is crucial to accompany a pull request with an issue for several reasons:
Context and Discussion: Giving context to your proposal and discussing it with the maintainers can help to ensure that the proposed change is aligned with the project's goals, architecture, and roadmap. This discussion helps set clear expectations and increases the chance of your pull request being accepted.
Documentation and Tracking: Issues act as a form of documentation, providing a historical record of the identified problem, proposed solution, and decision-making process behind the change. They help maintainers track the project's progress and prioritize tasks. At the same time, they also allow other contributors to understand the context and reasons behind the changes introduced in the pull request.
Reducing Back-and-Forth Communication: Discussing and agreeing upon the proposed changes in advance through the issue can reduce the back-and-forth communication during the pull request review process. This can save both your time and the maintainers' time.
Avoiding Unnecessary Work: Creating an issue allows maintainers to provide early feedback on the proposed change. They can advise if a similar issue exists, if the proposed change aligns with the project's goals, or if alternative approaches are preferable. This helps you avoid wasting time and effort working on something that may not be accepted because it conflicts with existing plans.
Avoiding Spam Pull Requests: Unsolicited (pull requests without an issue) and unwanted pull requests may be marked as spam because they're seen as introducing irrelevant, low-quality, or harmful changes to the project's codebase. Having your pull request marked as spam can lead to rejection, lost contribution opportunities, and potentially damage your reputation.
3. Ask to be assigned to an issue
Certain projects may have specific rules regarding the assignment of issues. Some projects may require permission before working on an issue, while others allow you to assign yourself to an issue. That's why reviewing the project's contributing guidelines is essential to knowing how to claim issues.
If the contributing guidelines don't state how to claim an issue, you can ask the maintainers to assign it to you. This will ensure no duplication and that your contribution is aligned with the project's goals and requirements.
You can leave a comment on the issue, like, "Can I please be assigned to this issue?" when the maintainer has assigned you, you'll notice that your username is now under the "Assignees" section.
Contribution Workflow :
Once a maintainer has assigned you an issue, the next step is to work on the changes. Here's a general workflow of the process:
1 Fork the Repository:
Forking a repository means creating a copy of the repository under your GitHub account. It allows you to push changes to the remote codebase without affecting the original project.
2 Cloned the Forked Repository:
Cloning your forked repository means making a copy of your forked repository to your local machine. Run the following command in your terminal:
git clone https://github.com/YOUR-USERNAME/REPOSITORY-NAME.git
Replace "YOUR-USERNAME" with your GitHub username and "REPOSITORY-NAME" with the repository's name.
3 Create a New Branch:
Before making any changes, create a new branch in your local repository to work on your contribution. Creating a new branch is the best practice in open source because it keeps your changes separate from the main branch.
You can create a new branch using the following command:
git checkout -b YOUR-BRANCH-NAME
Replace "YOUR-BRANCH-NAME" with a descriptive name for your branch, such as "fix-bug-123" or "add-new-feature".
4 Make Changes
Now that you have a new branch, you can change the codebase. Always follow the project's coding guidelines and conventions.
5 Run the Change Locally
You should always run and check your changes in your local environment, regardless of how small they are. This is important to ensure they work as expected and won't break production.
You can find the instructions on how to run a project locally in the README file or the contributing guidelines.
6 Add and Commit the Changes
Once you've made your changes, add your changes to the staging area and commit them with these commands:
git add .
git commit -m "Your commit message"
Replace "Your commit message" with a brief description of your changes.
7 Push the Changes
Push your changes to your forked repository on GitHub by running the following command:
git push origin YOUR-BRANCH-NAME
Replace "YOUR-BRANCH-NAME" with the name of your branch.
8 Working with a Pull Request
Create a Pull Request
Once you've pushed your changes, you can now create a pull request. To create a pull request:
Navigate to the original project's repository on GitHub.
Click the "Compare & pull request" button.
Fill in all required information in the template.
Click the "Create pull request" button
Fill In a Pull Request Template
Most projects provided a pull request template that is shown and needs to be filled in Markdown. This template guides you in providing all the information maintainers need to review your pull request.
Tips to Fill In a Pull Request Template
It can be challenging to read and fill in a pull request template. Here is some tips on how to fill one:
1. Preview Mode
Click the "Preview" tab to see the sections you must fill in before you do so. It'll be easier for you to notice them in this mode, but note that you cannot edit them in preview mode.
Here is an example of a pull request template preview mode screenshot.
2. Headings
Get back to the writing mode by clicking the "write" tab. Pay attention to the headings with # symbols. You need to provide information right under these headings.
3 Comments
The instructions on what information you must provide are usually written in the comments under each heading. You need to read and follow all instructions thoroughly.
TIP::: When filling in the information, write it below the comment so you can still see and follow the instructions.
Here is the template in Markdown. Now, pay attention to the heading and the comments as we discussed:
## Description
<!--
Please do not leave this blank
This PR [adds/removes/fixes/replaces] the [feature/bug/etc].
-->
## Related Tickets & Documents
<!--
Please use this format link issue numbers: Fixes #123
https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword
-->
## Mobile & Desktop Screenshots/Recordings
<!-- Visual changes require screenshots -->
## Steps to QA
<!--
Please provide some steps for the reviewer to test your change. If you have wrote tests, you can mention that here instead.
1. Click a link
2. Do this thing
3. Validate you see the thing working
-->
## Tier (staff will fill in)
- [ ] Tier 1
- [ ] Tier 2
- [ ] Tier 3
- [ ] Tier 4
## [optional] What gif best describes this PR or how it makes you feel?
<!-- note: PRs with deleted sections will be marked invalid -->
<!--
For Work In Progress Pull Requests, please use the Draft PR feature,
see https://github.blog/2019-02-14-introducing-draft-pull-requests/ for further details.
For a timely review/response, please avoid force-pushing additional
commits if your PR already received reviews or comments.
Before submitting a Pull Request, please ensure you've done the following:
- 📖 Read the Open Sauced Contributing Guide: https://github.com/open-sauced/.github/blob/main/CONTRIBUTING.md.
- 📖 Read the Open Sauced Code of Conduct: https://github.com/open-sauced/.github/blob/main/CODE_OF_CONDUCT.md.
- 👷♀️ Create small PRs. In most cases, this will be possible.
- ✅ Provide tests for your changes.
- 📝 Use descriptive commit messages.
- 📗 Update any related documentation and include any relevant screenshots.
-->
Don't skip and delete anything in the template
what's important is that you must fill in every section in the template that doesn't say "optional" or doesn't mean for the core team or staff to fill in. Also, you must never delete or modify the template, even if you think a section doesn't apply to your contribution.
if a section is irrelevant to your changes, leave a comment explaining why it's irrelevant or provide a brief "N/A" response. If you still need help with what to fill in, look at the previous pull requests and see how other contributors have done that.
Required information to Provide in most Pull Request Templates
Every project is unique. Each has its own pull request template structure and requires information to be provided. However, all projects typically require the following:
Title
Add a short and clear title that describes the changes that you make. For example, "Fix: button click function doesn't work"
Description
Explain your changes in as much detail as possible. What did you fix? How didi you fix it? Did you add a new function or modify a function? If there are several changes, consider using bullet points and providing links to the resources you use to back up your changes.
Here is an example:
## Description <!-- Please do not leave this blank This PR [adds/removes/fixes/replaces] the [feature/bug/etc]. --> This PR fixes the long repos' names that are partially stacked at the back of another name in the search input of the Explore tab. The changes made here: - Add Tailwind className: - [`truncate`](https://tailwindcss.com/docs/text-overflow#truncate) to truncate overflowing text. - [`tracking-tighter`](https://tailwindcss.com/docs/letter-spacing) to reduce letter spacing for better space. - `inline-block` to the `<span>` . - Remove Tailwind classNames: - `overflow-hidden` as it's [included in the `truncate`](https://tailwindcss.com/docs/text-overflow). - `break-all` as we don't want to add line breaks.Related Issue(s)
Most projects don't review unsolicited pull requests (pull requests that are not accompanied by an issue). One reason is to avoid spam pull requests that might introduce irrelevant, log-quality, or harmful changes to the project's codebase.
so, when you create a pull request, you want to include the related issue number. Add the keyword "Close", "Fixes" or "Resolves" in front of the issue number, for example, "closes #123.
Linking a pull request To an issue will automatically close the issue once the pull request gets merged.
You can find the issue number right after the title, as shown below.
Screenshots or screen recordings
If your changes relate to UI improvement, consider adding screenshots or screen recordings to show the before-and-after changes.
9 Respond to Feedback
After submitting your pull request, the project maintainers may provide feedback or request changes. Be sure to respond promptly and address any concerns or suggestions they may have.
By following these steps, you'll be able to submit your contributions to open-source projects and collaborate with other developers to improve the codebase.
What Happens Next?
After your contribution has been submitted and reviewed, one of the following outcomes may come.
Your contribution is accepted: If your contribution is approved by the project maintainers, it will be merged into the main branch of the codebase.
Congratulations! Your work is now part of the project, and you've made a valuable contribution to the open-source community.
Your contribution requires changes: Sometimes, the project maintainers may request changes to your contribution before it can be accepted. This could be due to coding issues, conflicts with other changes, or a need for additional documentation. In this case, make the request changes and resubmit your pull request.
Your contribution is rejected: In some cases, your contribution may not align with the project's goal or requirements, or it may not be the best solution to a problem. If your contribution is rejected, don't be discouraged. Take the feedback you received as an opportunity to learn and improve. You can always try contributing to another project or submitting a different contribution to the same project.
Conclusion
In the open-source world, it is not easy to be a part of, because open-source contribution takes a lot of patience of your contribution. Finding a project to become a contributor's journey is not so easy. Equire the right skills and try to contribute to the project's good first issues. keep trying to contribute to your desire projects.
