launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

Hi Robert,

I think this is a very worthwhile experiment.  I appreciate that you are 
bringing a cost/benefit analysis to one of the sacred cow of Launchpad.

You didn't state for how long we should run the experiment before making the 
evaluation? 

Your suggestion is to also do one random post-landing evaluation review per 
reviewer per month. Maybe we should do it every twice in the first month, once 
in the second month and then evaluate the experiment in two months (say at the 
Epic). The rationale being that we can spot and recover from any problems 
early on in the experiment.

In addition to UI and Database, should we add Javascript reviews to the must-
be-reviewed list? This is still an area where expertise isn't that spread out 
in the team.

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

On October 18, 2010, Robert Collins wrote:
> I've chatted in the last few reviewers meetings about the review
> process, costs / benefits, what we want from it and so on.
> 
> But thats all pretty vague stuff; I've got a specific experiment in
> mind that I think will at worst teach us what we value in reviews more
> clearly (e.g. for me its knowing that other folk can understand what
> I've done - I have problematic conceptual stuff hammered out way in
> advance).
> 
> https://dev.launchpad.net/PolicyAndProcess/OptionalReviews describes
> this experiment.
> 
> Just like intensive experience with TDD helps one learn whether a
> given change needs a test or doesn't, and what tests, experience with
> code reviews should have taught us what things are a net thing to have
> reviews on, which are a net loss and so on.
> 
> To save you needing to click through, here is the meat from the wiki page:
> ---
> Process Overview
> Some reviews are not needed and eligible developers can choose to have
> branches land without formal review.
> 
> Process Description
> Developers which are contributing at or near fulltime to Launchpad
> can, after 3 months, choose to land branches without review.
> 
> Each month, all code reviewers will be assigned one unreviewed landed
> to do a post hoc review as part of assessing the experiment.
> 
> Production problems which are tracked to unreviewed landings will also
> be input into assessing the experiment.
> 
> Rationale
> Not all changes benefit from code review / are high enough risk to
> need formal review. For instance (not exhaustive):
> 
> mechanical things (like moving code)
> updating source deps
> rollbacks
> typo fixes
> improvements to documentation
> For many of these things a review may add value - but less value than
> doing the review uses up. We want reviews to be a net win for the
> effort being put into developing Launchpad, and so we should, once
> we're comfortable people know how things should be, allow them to
> decide if a particular change is an improvement on its own, or an
> improvement that also /needs/ other input before landing.
> 
> Triggers
> Experienced developer (someone currently working on LP who has been
> doing so for the last 3 months) landing a code change (not UI or
> Database, for now : evaluate after assessing the success of optional
> code reviews).
> 
> Activities
> Submit the branch to create an MP (our toolchains can look at this and
> it provides a location for a post landing review if the branch has
> that done to it). Self review with review type 'unreviewed'. Land via
> the normal landing process.
> ---
> 
> What do you think?
> 
> -Rob
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: This is a digitally signed message part.