<div dir="ltr"><div><div><div><div>Perhaps we should split this into "code review tied to a phab task" vs. "code review that does not have an associated phab task". <br><br></div>TPG probably has no visibility into the latter (if those even exist). <br><br></div>The former would be handled normally by my (and probably other TPGer's) regular processes. The task would either get stuck in the "In Progress" or "Under review" column, and after a day or two, we would start asking the team why it isn't moving. In the case of Discovery, Dan would often notice it and start asking about it even before I would. <br><br></div>So I think the answer to the first part of your original question would be: Yes, we would encourage regular review grooming (via phab tasks). The process for Discovery describes the use of the "Needs Review" column, but doesn't go into specifics about WIP limits or how long something can sit there before being considered a problem. As I said, that's about 2 days for us. <br><br></div>I'm not aware of any data about teams that do better or worse about this. Discovery wouldn't objectively distinguish between internal and external contributions, but could make subjective calls about whether to push harder on something either because it's a critical internal thing, OR because we would want to avoid disappointing a volunteer. <br><div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Mar 18, 2016 at 5:21 AM, Andre Klapper <span dir="ltr"><<a href="mailto:aklapper@wikimedia.org" target="_blank">aklapper@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hej,<br>
<br>
thanks for the reply!<br>
<span class=""><br>
On Tue, 2016-03-15 at 17:20 -0700, Kevin Smith wrote:<br>
> TPG generally focuses on process and inter-personal issues, and<br>
> doesn't get into the tech itself.<br>
> So our focus tends to be at the phab task level, rather than at the<br>
> gerrit patch level.<br>
<br>
</span>As engineering tasks in Phabricator often require a code change going<br>
through review, I'd consider code review a part of the process to get<br>
Phabricator tasks resolved. <br>
Technical implementation details ("Gerrit") shouldn't be the main point<br>
of my request - it's rather the social aspect of interaction between<br>
authors and reviewers, and potentially documenting best practices<br>
across teams performing code review as part of their usual processes.<br>
<br>
Do you agree with that understanding?<br>
<span class=""><br>
> I think most TPGers happen to be embedded into teams that receive<br>
> relatively few external code submissions. <br>
<br>
</span>Let's ignore the "external contributions" aspect as I'd expect many<br>
aspects of code review to also apply when reviewing internal<br>
contributions.<br>
<br>
Thanks,<br>
andre<br>
<span class="im HOEnZb"><br>
> I wonder whether integrating code review into phab will give us some<br>
> new tools to help teams more easily monitor the flow of patches. I<br>
> don't know what tools are available in gerrit. <br>
> <br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> On Mon, Mar 14, 2016 at 6:19 AM, Andre Klapper <<a href="mailto:aklapper@wikimedia.org">aklapper@wikimedia.org</a>> wrote:<br>
> > Thanks everybody for the comments! However I'm still curious if this is<br>
> > part of the TPG scope, hence I'd welcome a reply from TPG members.<br>
> ><br>
> > Thanks,<br>
> > andre<br>
> ><br>
> > On Mon, 2016-03-07 at 14:16 +0100, Andre Klapper wrote:<br>
> > > <a href="https://phabricator.wikimedia.org/T101686" rel="noreferrer" target="_blank">https://phabricator.wikimedia.org/T101686</a> lists "Prioritization / weak<br>
> > > open source culture: more pressure to write new code than to review<br>
> > > patches contributed."<br>
> > ><br>
> > > Apart from whether that statement is true or not:<br>
> > > Does the Team Practices Group encourage regular Gerrit patch backlog<br>
> > > grooming? If so, how, and is there any documentation available, or even<br>
> > > data which teams perform better or worse? Is there any differentiation<br>
> > > between "internal" patches by team members vs. contributed patches?<br>
> > > Or is this out of scope for TPG?<br>
<br>
--<br>
Andre Klapper | Wikimedia Bugwrangler<br>
<a href="http://blogs.gnome.org/aklapper/" rel="noreferrer" target="_blank">http://blogs.gnome.org/aklapper/</a><br>
<br>
<br>
<br>
_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
</div></div></blockquote></div><br></div>