[teampractices] Code review before writing new code

[Quim Gil]

Thank you for this discussion! I have updated the description of
https://phabricator.wikimedia.org/T101686 based on the feedback received,
and will continue to do so.

I'm thinking of morphing this proposal into a WMF committed goal: *The code
review queue must stop growing and start decreasing*

Then each team and each individual would be free to take the approaches
that fit best with their workflows. Meanwhile, Team Practices and Community
Engineering could work on recommendations, activities, and metrics
supporting that goal, and product managers and line should be onboard when
planning new goals and sprints.

So far we have identified several problems (listed in T101686). As we dig
into the problems, we will identify specific problems and hopefully their
specific remedies. Does this sound better?

I have proposed in T101099: Engineering Community Roadmap
<https://phabricator.wikimedia.org/T101099> a sequence of goals to solve
the code review time wait problem in the next 12 months. T88531: Goal:
Organize a Gerrit Cleanup Day <https://phabricator.wikimedia.org/T88531> would
be the first step (awareness and official kick-off of the discussion),
followed by changing the trend (queue stops growing), cleaning up, and
committing to some kind of service-level agreement. I (or @Aklapper
<https://phabricator.wikimedia.org/p/Aklapper/>, or whoever is faster) will
create specific tasks to discuss these goals as soon as we have enough
feedback supporting this direction.

On Wed, Jun 10, 2015 at 10:41 AM, Gilles Dubuc <gilles at wikimedia.org> wrote:

> I think this is a cultural problem, which means that it will be difficult
> to solve by forcibly pushing people towards a specific way of fixing it.
> It's not a staff vs volunteer nor an active project vs abandoned project
> issue. Other open source projects with worse staff to volunteers ratios
> don't have that problem. We have to change the conditions and the landscape
> to produce a long-lasting cultural shift.
>
> The way I try to contribute at my own little scale is to always aim to
> review more changesets than I produce. If everybody did that, the issue
> would go away, right? And it doesn't have to be tied to a specific
> workflow, like reviewing before writing, etc. which wouldn't fit everybody
> and wouldn't even fit me every day. It doesn't matter how you organize your
> schedule as long as at the end of the week/month/year you've reviewed more
> changes than you've asked others to review.
>
> Maybe that specific way of seeing things (am I in review debt?) could be
> supported by software. I.e. a prominent indicator of whether or not you've
> pushed more changesets than you've reviewed. It might be something to
> consider once we move code reviews to phabricator. Moving away from gerrit
> should be a priority, in fact, as the increased ease of use and integration
> of our review tool could have an impact on those figures.
>
> On Wed, Jun 10, 2015 at 2:00 AM, James Douglas <jdouglas at wikimedia.org>
> wrote:
>
>>  > Exactly. And thus a team prioritizing Bar might continue coding on
>> Bar, allowing the queue of pending Foo code reviews to pile up.
>>
>> Bingo!
>>
>> On Tue, Jun 9, 2015 at 1:55 PM, Kevin Smith <ksmith at wikimedia.org> wrote:
>>
>>>
>>> On Tue, Jun 9, 2015 at 1:10 PM, James Douglas <jdouglas at wikimedia.org>
>>> wrote:
>>>
>>>> This prioritization then makes it trivial to decide between reviewing
>>>> (or fixing, testing, deploying, etc.) feature Foo vs. coding up feature Bar.
>>>>
>>>>
>>> Exactly. And thus a team prioritizing Bar might continue coding on Bar,
>>> allowing the queue of pending Foo code reviews to pile up.
>>>
>>> Kevin
>>>
>>>
>>> _______________________________________________
>>> teampractices mailing list
>>> teampractices at lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>>
>>>
>>
>> _______________________________________________
>> teampractices mailing list
>> teampractices at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150610/a30692b6/attachment.html>