<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">Hey Matthew,</div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><blockquote type="cite"><div dir="ltr"><ol><li>we work on the code until we believe it is done</li></ol></div></blockquote>Don't wait until you're finished to open the PR. I tend to open one early on so other people are free to look through my code as they please. It also makes it easier to ask people to have a look over something you're not sure on. If you get feedback early rather than waiting until the end, you run less risk of the 'have you seen gem X' or 'try using this approach' feedback that can lead to delays while you refactor all the things. </div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><br></div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">You could also deploy the feature branch for QA before it has been merged depending on the state of the branch. Again, getting early feedback on any potential issues before you're too far down the garden path.</div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><br></div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">In terms of context switching, I try and be pretty descriptive with feedback on PRs. E.g how about we do this specific thing rather than 'this method looks smelly'. The later style of feedback can be a massive time sink in my experience. I hope by providing constructive / focused feedback to minimise any disruption I guess.</div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><br></div><div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">George</div><br><div><br></div></div><div><br>On 19 Aug 2013, at 13:38, Matthew Rudy Jacobs <<a href="mailto:matthewrudyjacobs@gmail.com">matthewrudyjacobs@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">(This is a process question, rather than a Ruby question)<div><br></div><div>How do you folks manage getting code from pull request to production?</div><div><br></div><div>At Enthuse.me we work in the following way;</div>
<div><div><ol><li>we take a card<br></li><li>we work on the code until we believe it is done</li><li>we issue a pull request</li><li>another member of the team takes a look at the pull request</li><li>we converse about any issues</li>
<li>we make any changes</li><li>another member of the team merges the pull request</li><li>the code is deployed to the QA server</li><li>the product owner checks the function on QA</li><li>the code is deployed to Production</li>
</ol><div>This all seems to be fine,</div></div><div>but the problem is context switching.</div><div><br></div><div>Steps 4 to 8 can take a couple of days to run through.</div><div><br></div><div>Maybe I finish the code on Friday, but no one is free to review it until Monday.</div>
<div>I start working on something else, then someone raises an issue with my PR.</div><div>When I'm next free I take a look, deal with their questions, make some changes, and ask them to take a look again.</div><div>
<br>
</div><div>That process takes a lot of time, and requires both the reviewer and myself, to switch back and forth.</div><div><br></div><div>How do you deal with this?</div></div><div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Chat mailing list</span><br><span><a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a></span><br><span><a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a></span><br></div></blockquote></body></html>