Skip to content

Instantly share code, notes, and snippets.

@rrgayhart

rrgayhart/os-contributions.md

Last active December 21, 2015 00:25
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save rrgayhart/72e5c2e4e0f0f50247bb to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save rrgayhart/72e5c2e4e0f0f50247bb to your computer and use it in GitHub Desktop.
Download ZIP
Tips and Tricks for Contributing to Open Source Over Break
Raw
os-contributions.md

Picking A Project to Work On

  • Find a Repo that is primarily written in a language you're comfortable with.
    • Check out 24pullrequests.com
    • Talk to mentors that regularly contribute to open source for suggestions
    • Think about tools you already use like rspec or minitest.
    • Browse around Github
  • Avoid 'dead' repos - look at open PRs for the project - if a ton unmerged, project may be dead. Also look at stars for the repo and last commit date on master.
  • Look at the open issues for ones you can help with
  • Look at coverage reports and builds for areas that are untested
  • Fork the repo
  • Timebox trying get the project running locally
    • Keep track of this process - your PR contribution may be to add instructions to a CONTRIBUTING.md or README.md file so future developers can get up and running fast.
  • Consider commenting on an issue or creating one (don’t claim an issue if you don’t feel 80% confident you’ll complete it) or contact the repo owner directly

Picking An Issue

  • Fixing and Refactoring is generally better than adding new functionality when you first start contributing to a repo.
  • Non-Code contributions are always appreciated - documentation is hard. Update the README with any set up instructions that you went through that weren't in it already, make spelling and grammar fixes. they-love-them

Some Things to Consider

  • Think about if the issue you want to fix requires environmental variables to run that you don’t have.
  • Avoid introducing new dependencies to a project (i.e. gems, node modules, etc)
  • Read the contribution rules for the repo if they have them
  • Don’t Expect to Get Things Merged

Making the Fix

  • Work on a branch that is well named, off of a fork of the repo
  • Be conscious and clean with your git commits and squash any commit that says ‘WIP’.
  • Make sure you follow any contribution rules in the project README
  • Run jshint or reek and make sure you didn’t make any syntax errors

PRing the Work

  • Once work is done, make sure to get the latest master from the repo and merge it into your branch and rerun tests and manual QA
  • Consider having a mentor review your work.
  • Submit a pull request with your changes.
    • Reference the issue if there is one related.
    • Make sure your pull request comment includes what the change is, why you made it. Give the repo owner any information they need to merge the pull request up front.
    • Consider tagging the mentor you had review your work in the PR so they can leave feedback
  • Brace yourself to receive PR comments and suggestions
  • Make changes as they are requested
    • make sure newest master is merged into your local branch, rerun tests, manual QA
    • push the changes to your remote branch
    • tag the person who requested the changes to review them.

Conclusions

Don’t be afraid. No one should make fun of your code. If they do, they are jerks. You will likely get feedback and suggestions - or polite rejections if the code doesn’t fit with the repo owner’s style or goals. Be ready to try many repos and many issues before you find one you can fix and feel confident in PRing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment