* Extract Git, Rails, and iOS protocols. * Move Rails-specific code review to Rails protocol. * Make git protocol less Rails-specific (instead of `rake`, say "run tests" so it can continue to apply to iOS, Haskell, etc. projects). * Nest bullets. * Use consistent capitalization.
* Removes short URLs * Makes it easier to see what you're being linked to * Improves readability by removing long, inline URLs
Since GitHub introduced [relative links in markup files](https://github.com/blog/1395-relative-links-in-markup-files), links with absolute paths such as `/thoughtbot/guides/blob/master/...` will no longer work.
Asychronous code review via Github pull requests can be incredibly efficient, but easy to accidentally offend or miscommunicate if we aren't careful about our language choices or have a common expectation of how to act when reviewing and responding to reviews. This new guide attempts to set some basic expectations to streamline code reviews and help us stay happy, healthy, and working closely as a team. * Distinguish between discussions that are appropriate for code reviews versus those that are appropriate for technique discussions. * Include simplicity as a goal. * Summarize offline conversation. * Show, not tell, how to link to project management system ticket. * Clarify sign off.