How to start contributing to Open Source

Includes content based on github.com/github/opensource.guide used under the CC-BY-4.0 license.

Michael Kühnel

  • Doing stuff for the Internet since Netscape 4.7
  • Frontend Developer at Micromata
  • Open Source Fan
  • Yeoman Core Team Member
  • Proud Member of the bullgit Family

Meaningful contributions?

Every contribution is meaningful 💖

There are no contributions which are to tiny

Seriously, [documentation] is mega-important. The documentation so far has been great and has been a killer feature of Babel. There are sections that could certainly use some work and even the addition of a paragraph here or there is extremely appreciated.

– Sebastian McKenzie

What could you contribute?

Improvement of documentation

– even fixing typos and dead links –

Performance improvements

– even compressing images –

Code removal

– e.g. outdated browser workarounds –

Updating dependencies

Adding tests

Bugfixes

New features

Demo Time

How to choose a project to contribute

Choose something you love and use regularly

Check the following before diving in

How well is the project maintained?

  • Latest commit
  • Latest release

  • Issues

  • Pull Requests

How welcoming is the project?

  • Do the maintainers respond helpfully to questions in issues?
  • Are people friendly in the issues, discussion forum, and chat

  • Do pull requests get reviewed?

  • Do maintainers thank people for their contributions?

Hint

Watch the repository for while

  • Get notified of all conversations

  • Get to know community members, before doing work that might not get accepted.

 

What to do before contributing

Check the most important files

  • License
  • Readme
  • Contribution Guidelines
  • Code of Conduct

Talk to the maintainers

If you go to an issue tracker and things seem confusing, it’s not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.

@shaunagm

Be nice

Maintainers are busy persons who spent a lot of their spare time to create and improve software you are using for free

Communications channels

  • Issues are like starting a conversation or discussion
  • Pull requests are for starting work on a solution
  • For lightweight communication, such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channel

Thinks to consider when communicating

💚  “X doesn’t happen when I do Y”


❌  “X is broken! Please fix it.”

Give context

💚  “I’m not sure how to implement X. I checked the help docs and didn’t find any mentions.”

 

❌  “How do I X?”

Do your homework beforehand

💚  I’d like to write an API tutorial.”

 

❌  “I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you …“

Keep requests short and direct

💚  “Thanks for looking into this error. I followed your suggestions. Here’s the output.”

 

❌  “Why can’t you fix my problem? Isn’t this your project?”

It’s okay to ask questions (but be patient!)

💚  “I’m disappointed you can’t support my use case, but as you’ve explained it only affects a minor portion of users, I understand why. Thanks for listening.”

 

❌  “Why won’t you support my use case? This is unacceptable!”

Respect community decisions

Explore the project 👨‍🔬

  • Dependencies
  • Architecture
  • Code Style
  • Tooling
  • etc.

Start with an easy bug or feature

See resources on the last slide

Get ready to contribute

Open an issue to

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

Make sure to check for existing before to prevent duplicates!

Tips for communicating on issues

  1. If you see an open issue that you want to tackle, comment on the issue to let people know you’re on it.
  2. 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. 
  3. 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.

Open a pull request to

  • Submit trivial fixes (eg. a typo, broken link, or obvious error)
  • Start work on a contribution that was already asked for, or that you’ve already discussed, in an issue

– Hint –

A pull request doesn’t have to represent finished work.

It’s usually better to open a pull request early on, so others can watch or give feedback on your progress.

Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later.

Steps to open a pull request

  1. Fork the repository
  2. Create a branch
  3. Contribute in the style of the project
  4. Add commits
  5. Test your changes!
  6. Create the pull request
    • Describe your changes
    • Reference any relevant issues
    • Include screenshots of the before and after if applicable
  7. Remember that pushing new commits to your branch will update the pull request

Thats it! 

Congratulations on becoming an open source contributor

Ressources

📚

Finding beginner issues

Articles related to getting started with OSS

Additional links regarding OSS

Questions? 

Thanks 😊

How to start contributing to Open Source

By Michael Kühnel

How to start contributing to Open Source

This presentation gives you answers about what you need to know when like to start to contribute to Open Source Software.

  • 477
Loading comments...

More from Michael Kühnel