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

whoami @mattstratton - ChefConf 2017

Who is this talk for? » Enterprise Architects » Solution Architects » Customer Architects » are you seeing a pattern? @mattstratton - ChefConf 2017

No content

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

A small example from my own history mattstratton/devopsdays vs chef-cookbooks/delivery-sugar @mattstratton - ChefConf 2017

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

Where do I start? @mattstratton - ChefConf 2017

Solve someone else's problem @mattstratton - ChefConf 2017

Scratch your own itch @mattstratton - ChefConf 2017

Don't just make your own thing @mattstratton - ChefConf 2017

What not to contribute @mattstratton - ChefConf 2017

Working with maintainers » Follow the contibuting guidelines » Make your changes small and understandable » Test your stuff » Don't take it personally @mattstratton - ChefConf 2017

Follow contributing guidelines @mattstratton - ChefConf 2017

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

Make your changes small and understandable @mattstratton - ChefConf 2017

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

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

Test your stuff @mattstratton - ChefConf 2017

Share the results of your testing @mattstratton - ChefConf 2017

Don't take it personally @mattstratton - ChefConf 2017

“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

Advice from the field @mattstratton - ChefConf 2017

Here are some friends github.com/sous-chefs @mattstratton - ChefConf 2017

It's all going to be fine @mattstratton - ChefConf 2017

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

Even More Resources! » arresteddevops.com » github.com/mattstratton/speaking » twitter.com/mattstratton » speakerdeck.com/mattstratton @mattstratton - ChefConf 2017

Thank You @mattstratton - ChefConf 2017