<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Good ideas all around. Might not hurt to add these practices to
readme files so that lead contributors and new hires can join the
parade. <br>
<br>
<br>
<div class="moz-cite-prefix">On 9/29/14 3:49 PM, Gavin Suntop wrote:<br>
</div>
<blockquote
cite="mid:E539D456-589B-484A-BB9A-A71B7AFD56C5@mozillafoundation.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
+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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:webmaker-dev-bounces@mozilla.org">webmaker-dev-bounces@mozilla.org</a>>
on behalf of Kate Hudson <<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Webmaker-dev@mozilla.org">Webmaker-dev@mozilla.org</a><br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/webmaker-dev">https://mail.mozilla.org/listinfo/webmaker-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Webmaker-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Webmaker-dev@mozilla.org">Webmaker-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/webmaker-dev">https://mail.mozilla.org/listinfo/webmaker-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>