[#4] Create Open Source trail

* Link to Dr. Nic's classic 8 steps article.
* Link to SemVer.
* Separate using open source, contributing open source, and maintaining
  an open source project.
* Promote NEWS and ChangeLog files.
* Promote SemVer.

README.md

@@ -28,6 +28,7 @@ Trails
 
 * [Git](/thoughtbot/trail-map/blob/master/trails/git.md)
 * [iOS](/thoughtbot/trail-map/blob/master/trails/ios.md)
+* [Open Source](/thoughtbot/trail-map/blob/master/trails/open-source.md)
 * [Postgres](/thoughtbot/trail-map/blob/master/trails/postgres.md)
 * [Rails](/thoughtbot/trail-map/blob/master/trails/rails.md)
 * [Refactoring](/thoughtbot/trail-map/blob/master/trails/refactoring.md)

trails/open-source.md

@@ -0,0 +1,57 @@
+Open Source
+===========
+
+Critical learning
+-----------------
+
+* Read [8 steps to fixing other people's code](http://rdd.me/tsf7khhg).
+* Watch [How to manage an open source project](http://vimeo.com/45214727).
+* Read the rubygems.org ["Make your own gem" guide](http://guides.rubygems.org/make-your-own-gem/).
+* Read the [Semantic Versioning specification](http://semver.org/).
+* Understand [software licenses](http://playbook.thoughtbot.com/choosing-platforms/software-licenses/).
+* Know what a [`NEWS` file](http://www.gnu.org/prep/standards/html_node/NEWS-File.html#NEWS-File) is.
+* Know what a [`ChangeLog` file](http://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs)
+  is and how it is formatted.
+
+Validation
+----------
+
+You are an everyday open source user when you can:
+
+* Evaluate a project based on quality of code, tests, documentation.
+* Evaluate a project based on responsiveness of maintainers to developers'
+  questions and feature requests.
+* Evaluate a project based on regularity of releases.
+* Evaluate a project based on the appropriateness of its license for your
+  needs.
+* Evaluate a project by downloading and trying it.
+* Search issues for a similar problem you're having.
+* Comment with additional data on issues that you're also having.
+* Submit new issues with good environment (Ruby version, OS, etc.) info,
+  error messages, and backtraces so the maintainer can quickly replicate it.
+
+You are an everyday open source contributor when you can:
+
+* Get annoyed by a defect or missing feature.
+* Find the source code.
+* Create a copy of the source ("fork" on Github).
+* Check out (`git clone`) the source.
+* Poke around the source in your editor and shell (`grep`).
+* Read the contribution guidelines.
+* Write a failing test in the style of the project's test suite.
+* Write code to make the test pass in the style of the project's codebase.
+* Make sure the entire test suite passes.
+* Create a patch (push to your fork on Github).
+* Submit a patch ("pull request" on Github).
+* If it exists, email the project's mailing list asking for feedback.
+
+You are an everyday open source maintainer when you can:
+
+* Document a clear public API.
+* Document where issues are managed, such as Github Issues.
+* Provide a clear place for questions, such as Stack Overflow. Only provide
+  a Google Group mailing list if you're ready to support it.
+* Know how to use major, minor, and patch version numbers.
+* Provide your code in easily accessible form (rubygems.org, Github).
+* Evaluate pull requests and provide kind, intelligent feedback.
+* Know which license to use.