On Tue, 2014-08-12 at 14:12 -0700, Joe Gordon wrote:
> Here is the full nova proposal on "Blueprint in Kilo: Runways and > Project Priorities" > > https://review.openstack.org/#/c/112733/ > http://docs-draft.openstack.org/33/112733/4/check/gate-nova-docs/5f38603/doc/build/html/devref/runways.html Thanks again for doing this. Four points in the discussion jump out at me. Let's see if I can paraphrase without misrepresenting :) - ttx - we need tools to be able to visualize these runways - danpb - the real problem here is that we don't have good tools to help reviewers maintain a todo list which feeds, in part, off blueprint prioritization - eglynn - what are the implications for our current ability for groups within the project to self-organize? - russellb - why is different from reviewers sponsoring blueprints, how will it work better? I've been struggling to articulate a tooling idea for a while now. Let me try again based on the runways idea and the thoughts above ... When a reviewer sits down to do some reviews, their goal should be to work through the small number of runways they're signed up to and drive the list of reviews that need their attention to zero. Reviewers should be able to create their own runways and allow others sign up to them. The reviewers responsible for that runway are responsible for pulling new reviews from explicitly defined feeder runways. Some feeder runways could be automated; no more than a search query for say "new libvirt patches which aren't already in the libvirt driver runway". All of this activity should be visible to everyone. It should be possible to look at all the runways, see what runways a patch is in, understand the flow between runways, etc. There's a lot of detail that would have to be worked out, but I'm pretty convinced there's an opportunity to carve up the review backlog, empower people to help out with managing the backlog, give reviewers manageable queues for them to stay on top of, help ensure that project priorization is one of the drivers of reviewer activity and increases contributor visibility into how decisions are made. Mark. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
