<div dir="ltr">Hi folks,<div><br></div><div>Thanks to everyone who privately pointed out that my email to Greg had an overly sarcastic and belittling tone.  Greg, sorry.  :-(  To everyone else, my apologies for how my email negatively affected the tone of this list; please call me out on it if I do something like this again.</div><div><br></div><div>Greg and I are still working out what the status of <a href="https://phabricator.wikimedia.org/T119908#1903835" target="_blank">T119908</a>, and what my offer to shepherd it signals.  I'll strive to be better about AGF when trying to understand a disagreement, and be more patient about the course of private conversations before letting them spill onto public mailing lists.</div><div><br></div><div>Rob</div><div><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 15, 2016 at 6:37 PM, Rob Lanphier <span dir="ltr"><<a href="mailto:robla@wikimedia.org" target="_blank">robla@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Tue, Mar 15, 2016 at 11:26 AM, Greg Grossmeier <span dir="ltr"><<a href="mailto:greg@wikimedia.org" target="_blank">greg@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><quote name="Rob Lanphier" date="2016-03-15" time="11:02:39 -0700"><br>
<span>> On Mon, Mar 14, 2016 at 12:40 PM, James Forrester <<a href="mailto:jforrester@wikimedia.org" target="_blank">jforrester@wikimedia.org</a>><br>
> wrote:<br>
><br>
> > On 14 March 2016 at 19:15, Greg Grossmeier <<a href="mailto:greg@wikimedia.org" target="_blank">greg@wikimedia.org</a>> wrote:<br>
> ><br>
> >> Backgroun:<br>
> >> * This started as this task in our Phab:<br>
> >>   <a href="https://phabricator.wikimedia.org/T121751" rel="noreferrer" target="_blank">https://phabricator.wikimedia.org/T121751</a> "Document best practices to<br>
> >>   amend a change written by another contributor"<br>
> >> * Lot's of discussion there about what is "right" in the general sense.<br>
> >> * Mukunda found out a way of making everyone happy (maybe)<br>
> >> * Mukunda proposed that solution upstream, then Evan P wrote a long<br>
> >>   opinion piece on code review social contracts and basically concluded<br>
> >>   that our social contracts are toxic (a theme we keep hearing...)<br>
> >> ** here: <a href="https://secure.phabricator.com/T10584" rel="noreferrer" target="_blank">https://secure.phabricator.com/T10584</a><br>
> >><br>
> >> [​I  pretty strongly disagree with Evan] Indeed, I'd be more blunt: I<br>
> > think it's actively disrespectful to peers – be they WMF staff, third party<br>
</span>> > staff, or volunteers alike – to *not* just tweak and merge their code.<br>
<span>> > For instance, when there's a typo/misplaced whitespace in a comment or it<br>
> > needs a quick manual rebase, refusing to fix and merge isn't a great<br>
> > practice. People's time is precious and as reviewers we should all take on<br>
> > the burden of minor changes, and not give trivial C-1s (or Differential<br>
> > equivalents) that push the review cycle out for another hour/week/year<br>
> > (depending on the respondent's availability).<br>
> ><br>
><br>
> I fully agree with this.  It troubles me to openly and strongly disagree<br>
> with Evan, because I have so much respect for him as an upstream BDFL.  We<br>
> have a lot to learn from him when it comes to being a healthy upstream.<br>
><br>
> That said, there is a very unhealthy contrarian attitude toward the<br>
> competition (GitHub) which he is fostering.  If you look at the comment<br>
> thread on T10584, you'll see some snark about GitHub's model being<br>
> "broken".  Somehow, forcing developers to extra middleware like arc<br>
</span>> *isn't* broken,<br>
<span>> but GitHub is broken.  Riiiight.<br>
<br>
</span>Snark both ways doesn't help.<br></blockquote><div><br></div></div></div><div>Nor does brushing off my point (and James' point) by sanctimoniously dismissing my point as snark.</div><div><br></div><div>You failed to bring any clarity to this conversation with this interjection.  I'm starting to come around to Yuri's point that he made in the <a href="https://phabricator.wikimedia.org/T119908#1903835" target="_blank">T119908 conversation starting the end of December</a>. </div><div><br></div><div>I'll requote one of James' more powerful statements: "People's time is precious and as reviewers we should all take on the burden of minor changes, and not give trivial C-1s (or Differential equivalents) that push the review cycle out for another hour/week/year (depending on the respondent's availability)."  Can you please respond to this?</div><span class=""><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> In reading Evan's comments (and not other Phab users), his instincts seem<br>
> to come from the Facebook new developer mentoring model, and may not be<br>
> entirely wrong.  We need to evaluate whether we want to join him in this<br>
> battle against the prevailing attitude popularized by GitHub.  Personally,<br>
> I think it's a quixotic losing argument, but ultimately, WMF Release<br>
> Engineering needs to decide where they are going to place their loyalty and<br>
> support.<br>
<br>
</span>I don't think it's a matter of "placing one's loyalty" as you term it.<br>
This isn't a war nor an election. It's a highly complex and nuanced issue<br>
of social norms and practices that is highly dependent upon<br>
circumstances and location. So no, I reject this characterization.</blockquote><div><br></div></span><div>Declaring this "complex and nuanced" doesn't bring clarity to it, and doesn't address James' points.  WMF Release Engineering is expressing its strong preference for moving from Gerrit to Differential.  You seem to be abdicating your team's responsibility as diplomats between this user community and the Phab upstream, and basically begging us to help you make an argument you are having a difficult time expressing yourself.</div><div><br></div><div>Are you asking one of us to take over your team's job as spokespeople to upstream?  I'll note that the upstream conversation on <a href="https://secure.phabricator.com/T10584" target="_blank">Upstream:T10584</a> includes the following comment from Mukunda:</div><div><br></div><div><div>> It took 6 months before I got my first patch accepted in gerrit. This is not an exageration.</div><div>> At my previous job I deployed to production within the first week.</div></div><div><br></div><div>Greg, do you believe that upstream's tracker is the best place for us to have that particular conversation?  I don't mind having this conversation publicly, but it seems more appropriate for us to discuss this in a Wikimedia venue.</div><div><br></div><div>Gergo and Subbu made excellent points on T10584, and I attempted to make my point more constructively.  Can your team represent our development community and development processes a little more charitably and constructively? </div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Instead, WMF Release Engineering will continue to work with all parties<br>to help think through code-review best practices, along with TPG and<br>the Architecture Committee as leaders/supporters.</blockquote><div><br></div></span><div>It seems a little presumptuous to expect ArchCom's support.  Do you believe that you deserve it?</div><span class=""><font color="#888888"><div><br></div><div>Rob</div><div><br></div><div> </div></font></span></div></div></div>
</blockquote></div><br></div></div></div>