launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

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