* 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.
A more recent version of this guide has been moved and edited in the playbook: https://github.com/thoughtbot/playbook/blob/master/book/one-weeks-iteration.md Rather than maintain two versions and potentially cause confusion about where to look for the process, I think we should stick to just the playbook version.
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.