Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Handwaver's Guide to Contributing To Open S...

The Handwaver's Guide to Contributing To Open Source - ChefConf 2017

Talk given at ChefConf 2017

Full PDF with speaker notes available at https://github.com/mattstratton/handwavers-guide/blob/master/handwavers-guide.pdf

Matt Stratton

May 24, 2017
Tweet

More Decks by Matt Stratton

Other Decks in Technology

Transcript

  1. Who is this talk for? » Enterprise Architects » Solution

    Architects » Customer Architects » are you seeing a pattern? @mattstratton - ChefConf 2017
  2. Why contrbute rather than start fresh? » You don't really

    know what you're doing » You're working totally alone » Chance are, you'll follow some major anti-patterns » Heck, you might invent some of your own! @mattstratton - ChefConf 2017
  3. Don't call it an agenda » Determining when to conribute

    » Don't go it alone » What not to contribute » How to work with containers maintainers @mattstratton - ChefConf 2017
  4. Working with maintainers » Follow the contibuting guidelines » Make

    your changes small and understandable » Test your stuff » Don't take it personally @mattstratton - ChefConf 2017
  5. CONTRIBUTING.md From spf13/hugo Code Contribution Guidelines To make the contribution

    process as seamless as possible, we ask for the following: - Go ahead and fork the project and make your changes. We encourage pull requests to allow for review and discussion of code changes. - When you’re ready to create a pull request, be sure to: -- Sign the CLA. --Have test cases for the new code. If you have questions about how to do this, please ask in your pull request. --Run go fmt. --Add documentation if you are adding new features or changing functionality. The docs site lives in /docs. --Squash your commits into a single commit. git rebase -i. It’s okay to force update your pull request with git push -f. --Ensure that make check succeeds. Travis CI (Linux and macOS) and AppVeyor (Windows) will fail the build if make check fails. --Follow the Git Commit Message Guidelines below. @mattstratton - ChefConf 2017
  6. A bad change: PR#341 - Fixes some stuff A good

    PR: PR#341 - Enable the use of TOML in addition to YAML in configuration files @mattstratton - ChefConf 2017
  7. Sometimes being pedantic isn't a bad thing There's a reason

    we have conventions in commit messages. Good commit messages follow these guidelines1 » Initial caps » Short introductory summary » Describes the change in an imperative manner 1 Except when they don't. @mattstratton - ChefConf 2017
  8. “One of the hardest parts of being a maintainer is

    saying “No” to patches you don’t want. - Jessie Frazelle2” 2 "The Art of Closing" from Jessie Frazelle's Blog @mattstratton - ChefConf 2017
  9. Further Resources » learn.chef.io (Open Source Collaboration module) » gitforteams.com

    (Emma Jane Hogbin Westby) » http://codeinthehole.com/tips/a-useful-template- for-commit-messages/ » https://github.com/m1foley/fit-commit » Open Source Governance 101 by Nell Shamrell- Harrington @mattstratton - ChefConf 2017