Contribution in OpenSource projects

Amit Kumar Gupta
4 min readMay 22, 2018
Photo by rawpixel on Unsplash

In the attempt of motivating people for #opensource development, I’ve received response from approx 18 contributors in 4 weeks. With this experience I would like to share a #guideline with all the fresh #contributors and the authors who welcome fresh contributors.

Authors

Accepting contribution from #first_timers is not just about taking support for your project but also to provide support in return. People, contributing first time, are generally afraid to commit mistakes. Hence they hesitate.

If you really want to motivate first timers, you should take extra care while creating an issue.

  • Easy: It should not take much effort and time to complete an issue. They should be easy to understand.
  • Have Patience: You may need to spend more time in creating an issue than solving it. Be ready for that. Have a look on this issue, it’ll take hardly 10 mins to solve it. But I spent more than 20 mins to write it and make it more explainable. Be ready to spend extra time to review their work.
  • Contribution Guideline: Don’t expect fresh contributors to read contribution guideline. They may miss it. It’s better to mention some important point on issue itself.
  • Documentation: Many good projects don’t have easy to understand documentation. Or the documentations are placed on some place which is not known by their visitors. For the opensource project Stubmatic I initially created documentation on wiki. But when I received many basic questions, I realized that I should link them on README as it is the initial point for any visitor.
  • Credit: Don’t forget to appreciate their work. You may also display the list of contributors on README of your project.
  • Guideline: On README.md, CONTRIBUTING.md, or on issue itself provide a link which guide first time contributors about how to raise a PR.

It is also difficult for fresh contributors to find out projects or issues which are suitable for them and someone can guide. So always ensure that your message about accepting contribution is loud & clear and reaches to the right audience. For that

https://github.com/NaturalIntelligence/imglab
  • You can also put a first timer friendly badge.
[![first-timers-only](http://img.shields.io/badge/first--timers--only-friendly-blue.svg?style=flat-square)](http://www.firsttimersonly.com/)
  • You can tweet issues with @first_tmrs_only and @yourfirstpr handlers.
  • Label an issue with “first-timers-only”, or “ good first issue”. There are some good sites /communities like issuehub.io which helps contributors to find issues with particular labels. You can also check up-for-grabs, codetriage, and yourfirstpr to find contributors.
  • Create CONTRIBUTING.md in the root of your project. It indicates that you’re accepting contribution. Reserve a section for first-time-contributors also.

Besides that you should clearly mention your expectation in contribution guideline and link it in the issues. Make sure to review the work done by contributors. There is a possibility of using anti-patterns, or lengthy & complex solutions. They may leave some part to do or some part to test. Have patience, keep guiding.

Other useful links

Contributors

Photo by Tim Gouw on Unsplash

> Yes, it’s scary. But SO rewarding! — firsttimersonly.com

There are many ways you can find the right project /issue to contribute. It is not necessary to write complex algorithms only. You can start with just the spelling correction in a documentation. There are many authors create trivial issues to welcome and support first timers. If a project is accepting contribution from first timers, they are ready to guide you on your mistakes.

There are some points that every first time contributor should take care.

  • Do some homework: Understand the basic of git, github and creating Pull Requests instead of asking project author for this.
  • Claim the issue first: This is the first step to tell author that you’re willing to work on an issue. Many contributors raise the PR directly without claiming an issue. Sometimes it is fine. But it may raise the situation when multiple contributors start working on the same issue.
  • Don’t rush: Understand the issue and clear your doubt before claiming it. I’ve faced the situations when people claim for an issue and then stop responding. It may create negative impact on the project and author. It stops other contributors too to claim this issue. It is good to leave a polite note stating your engagement with other projects /work.
  • Don’t stretch: If you complete an issue in long time, there is a possibility that other developers finish their part and you face code conflicts which may increase code complexity for you. So it is always good to complete an issue ASAP.
  • Work on a single issue at a time.
  • Mention the issue number either in PR detail or in commit message.
  • Read the CONTRIBUTING.md that you can find in root of github project, and PULL_REQUEST_TEMPLATE.md that you can find in .github folder.
  • First contribution may be trivial but will boost you with the confidence. Look for more challenging issues.

Other Useful Links

Disclaimer

I’m the author of 7–8 open source projects and welcome contributors. Please comment to contribute.

--

--