Open Stack

On 28 August 2013 06:32, John Griffith <john.griffith at solidfire.com> wrote:

> All great ideas, but really isn't the core of the issue rate of new patches
>  > rate of available reviewers?
>
> Seems to me that with the growth of the projects and more people
> contributing the number of people actively involved in reviews is not
> keeping pace.  Then throw in all of the "new" projects which takes at least
> a portion of someone who used to do all Nova all the time and now they're
> spreading that work-load across 3 or 4 projects it seems the only solution
> is more reviewers.
>
> Prioritizing and assigning maintainers is a great idea and I think we've all
> kinda feel into that unofficially any way, but there is a need for more
> quality reviewers and to be quite honest with all of the new projects coming
> in to play I think that problem is going to continue in to the next release
> as well.

I suspect so too. In the tripleo projects, I personally try daily to
ensure that any proposal in the tripleo projects gets a review (that
hasn't already been -1'd by another reviewer or failed validation).
Clearly this doesn't scale on an individual basis as the rate picks up
- but it's more important for scaling both the review team and
contributor sizes that feedback on proposals is received promptly and
early.

So I'd like to throw two ideas into the mix.

Firstly, consider having a rota - ideally 24x5 but that will need some
more geographical coverage I suspect for many projects - of folk who
spend a dedicated time period only reviewing. Reviewing is hard, and
you need to take breaks and let the brain decompress - so the rota
might be broken down to 2 hour periods or something. Launchpad [the
project, not the site] did this with considerable success : every
qualified reviewer committed to a time slot and didn't *try* to code -
they focused on reviews. A variation on this was to focus on doing
reviews when the reviewee was around - they'd get pinged on IRC and
then look at the review and be able to ask questions in realtime.
Really busy projects might need more concurrent reviewers, and we'd
want to ensure +2'd stuff gets a second +2-capable review quickly, so
it doesn't go stale unnecessarily.

Separately, and this is perhaps contentious; maybe folk that are
reviewers should deliberately not take on large bodies of work and
instead focus on being 50% or even 75% time doing reviews? The most
readily available source of skilled reviewers familiar with our code
bases is the existing reviewers... where companies are sponsoring us
to to work on OpenStack, this should be a straight forward discussion
- we all want OpenStack to be wildly successful, and this is a very
important part of scaling projects, though it is at the cost of
contributor time. However, bottlenecks are where work builds up, and
we don't have a 'write some code' bottleneck : we have 'design the
system' and 'review changes' bottlenecks.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud