[teampractices] Code review before writing new code

Gilles Dubuc gilles at wikimedia.org
Wed Jun 10 08:41:17 UTC 2015


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150610/2152fd8a/attachment-0001.html>


More information about the teampractices mailing list