Open Stack

On Thu, Aug 7, 2014 at 10:05 AM, Stefano Maffulli <stefano at openstack.org> wrote:
> On Wed 06 Aug 2014 02:10:23 PM PDT, Michael Still wrote:
>>  - we rate limit the total number of blueprints under code review at
>> any one time to a fixed number of "slots". I secretly prefer the term
>> "runway", so I am going to use that for the rest of this email. A
>> suggested initial number of runways was proposed at ten.
>
> oooooh, I like the 'slots/runaway model'. Sounds to me like kan ban (in
> the Toyota sense not the hipster developer sense).
>
> A light in my head just went on.
>
> Let me translate what you're thinking about in other terms: the
> slot/runaway model would switch what is now a push model into a "pull"
> model. Currently we have patches coming in, pushed up for review. We
> have then on gerrit reviewers and core reviewers shuffling through
> these changesets, doing work and approve/comment. The reviewers have
> little to no way to notice when they're overloaded and managers have no
> way either. There is no way to identify when the process is suffering,
> slowing down or not satisfying demand, if not when the backlog blows
> up. As recent discussions demonstrate, this model is failing under our
> growth.

I agree, although I hadn't thought of the length of the backlog as
something that we could use to report on our overload until you
mentioned it. I think there is a risk here, because it would be naive
to assume that the solution to a long review backlog would be to add
more core reviewers -- we need to be careful about quality as well as
quantity.

> By switching to a model where we have a set of slots/runaway (buckets,
> in Toyota's terminology) reviewers would have a clear way to *pull* new
> reviews into their workstations to be processed. It's as simple as a
> supermaket aisle: when there is no more pasta on the shelf, a clerk
> goes in the backend and gets more pasta to refurbish the shelf. There
> is no sophisticated algorithm to predict demand: it's the demand of
> pasta that drives new pull requests (of pasta or changes to review).
>
> This pull mechanism would help make it very visible where the
> bottlenecks are. At Toyota, for example, the amount of kanbans is the
> visible way to understand the capacity of the plant. The amount of
> slots/runaways would probably give us similar overview of the capacity
> of each project and give us tools to solve bottlenecks before they
> become emergencies.
>
> I think you guys are on to something, I'd be very happy to formalize a
> proposal. Who should I talk to?

You should ping John Garbutt and Dan Smith, as they're the ones I
recall tricking.

Michael

-- 
Rackspace Australia