<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">+1 to letting contributors know what we’re doing for them.<br><div><div><div apple-content-edited="true"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br></div></div><div><div>On Sep 29, 2014, at 12:38 PM, David Humphrey <<a href="mailto:david.humphrey@senecacollege.ca">david.humphrey@senecacollege.ca</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I very much agree with this. Being able to wield git to the same level that we do shouldn't be expected for a new contributor. At the same time, I think it's valuable to not do things silently either; that is, if you rebase a patch for someone, and fix a few things, let them know what you did so they can learn and maybe do it next time. Our process should be as open as our code, or it's not easily learned.<br><br>Dave<br>________________________________________<br>From: Webmaker-dev <<a href="mailto:webmaker-dev-bounces@mozilla.org">webmaker-dev-bounces@mozilla.org</a>> on behalf of Kate Hudson <<a href="mailto:kate@mozillafoundation.org">kate@mozillafoundation.org</a>><br>Sent: Monday, September 29, 2014 2:54 PM<br>To: Webmaker dev<br>Subject: Contributor rebase/merge issues<br><br>Hi everyone,<br><br>I wanted to say a little something about handling merge conflicts and other “process" issues in contributor patches.<br><br>Typically when a contributor has submitted a patch and the reviewer finds that it has conflicts and/or other minor process errors (squashing, etc.), the reviewer ill fail the patch and request the contributor fix those errors before review continues or the patch can be merged.<br><br>I think in cases where the conflict is easily resolved by the reviewer, we should consider putting the burden of rebasing/squashing on ourselves instead of contributors. There may be cases where this is not appropriate, such as if the conflict is better understood by the contributor, or the contributor has explicitly expressed interest in learning more about git. But more often than not, contributors just want to land their stuff and move on. So do we.<br><br>This is a policy I’ve noticed (and appreciated) in other open source projects and I’d love to hear what people think.<br><br>- K<br>_______________________________________________<br>Webmaker-dev mailing list<br><a href="mailto:Webmaker-dev@mozilla.org">Webmaker-dev@mozilla.org</a><br>https://mail.mozilla.org/listinfo/webmaker-dev<br></blockquote></div><br></div></div></body></html>