Why Ethics In Contributing To Open-Source Matters

Hello Fellow Codenewbies 👋,

Recently I collaborated with some of my community members to create members' guides and made contributions to the repository.
The experience allowed me to take a closer look at open-source.

I learned so much from these contributions. Whenever I encountered a technical problem, I would Google it or ask questions. But I also learned things along the way that I find as important as the technical ones.
That there are (unwritten) ethics in contributing to an open-source.
What are those ethics, and why do they matter?

---

Read The README.md File

When you're interested in contributing to an open-source, first you need to read the README.md.
The README.md contains all things about the open-source, and one of them is a contribution guide.
Contributing processes and requirements are different from one open-source to another. The contribution guide contains explanations of how to contribute to their repository.

If you cannot find the contribution guide in the README.md, you can try to find it in a file named CONTRIBUTING.md.

This is very important. As contributors, we have to be respectful by following their rules and code of conduct.

Good First Issue

A good-first issue is a GitHub issue or pull request that has been marked by its creator as appropriate for beginners.
-- VMWare - Open Source Blog

I opened an issue. I've explained the bug and what we need to do.
I also mentioned that this issue is beginner-friendly. So I would leave it for first-timers who want to contribute to open-source. After passing the check from a maintainer, the issue is labeled as a good-first-issue.

The shocking and sad part was people who deliberately worked on the issue were not beginners.

If you already have some experience, please consider leaving this label. It is meant for first-timers in open source and beginners in the field.

Ask Permission Before Working On An Issue

One of the most important (unwritten) ethics is to ask permission from the maintainer to work on an issue.

You want to avoid creating a pull request without asking for permission and waiting for a green light from a maintainer.
If you ignore this part, fat chance, your pull request will be ignored or turned down. Even after you put your time and hard work into fixing the issue, they will give it to those who ask.
It would be a great loss for you.

How to ask permission:

• Check the comment threads. See if the issue is already assigned to someone or if there is any other information about the issue.
• Leave a comment to request the maintainer if you can work on the issue. You can say something like, "Hi, I would like to work on this issue."
• Wait until the maintainer replies to your message. If they say you can have it and assign it to you, only by then you start to work on the issue and, in the end, create a pull request.

Good Communication

Always use clear and polite words to communicate with maintainers and other contributors.

If you're not sure about something, don't make assumptions. The best way is to communicate it with the maintainers for clarifications and/or guidance.

There are also times when a maintainer asks you to fix something in your pull request in a concise sentence.
Short and direct messages mostly happen because they are busy. So they need to be fast and effective in replying to messages.
So don't take it personally. It can lead to poor communication and losing your chance of contributing.

Use Templates

Some open sources give templates to open an issue or create a pull request.
But when they don't, consider writing them in a template of your own. This would be very useful for everyone to see the details. It would also help maintainers in their process of merging pull requests.

Consider having these in your template:

Open An Issue

• Clear and descriptive title

  By reading a clear and descriptive title, everyone can understand the issue. For example, "Link to the about page goes to the contact me page."

• Searched issues

  Check open and closed issues if there is the same issue as yours. If you don't find any, state that you've checked the whole issue in a description. We do want to avoid any duplication.

• The issue

  Describe the issue that you found and where did you find it.

• Reproduce the problem

  What steps are to be taken until the issue is encountered. This would be useful for everyone to run the same steps and test it out.

• Expected behavior

  What kind of behaviors are expected.

• Actual behavior

  The actual behavior.

• Screenshots

  Provide some screenshots if necessary.

Pull Request

• Short, clear, and informative title

• A clear description of the fix

  Read this article for more explanation of the pull request naming convention.

• Link to the issue

  Refer the pull request to the issue. For example, "This pull request is to close issue #123".

Wrap Up

I hope now you are aware that there are (unwritten) ethics in contributing to open source. Let's keep being respectful and keep the healthy environment of open source!

---

Thank you for reading!
Last but not least, you can find me on Twitter. Let's connect! 😊