Open Stack

On Wed, Aug 13, 2014 at 09:11:26AM -0400, Russell Bryant wrote:
> On 08/13/2014 08:52 AM, Mark McLoughlin wrote:
> > On Tue, 2014-08-12 at 14:26 -0400, Eoghan Glynn wrote:
> >>  > It seems like this is exactly what the slots give us, though. The core review
> >>> team picks a number of slots indicating how much work they think they can
> >>> actually do (less than the available number of blueprints), and then
> >>> blueprints queue up to get a slot based on priorities and turnaround time
> >>> and other criteria that try to make slot allocation fair. By having the
> >>> slots, not only is the review priority communicated to the review team, it
> >>> is also communicated to anyone watching the project.
> >>
> >> One thing I'm not seeing shine through in this discussion of slots is
> >> whether any notion of individual cores, or small subsets of the core
> >> team with aligned interests, can "champion" blueprints that they have
> >> a particular interest in.
> >>
> >> For example it might address some pain-point they've encountered, or
> >> impact on some functional area that they themselves have worked on in
> >> the past, or line up with their thinking on some architectural point.
> >>
> >> But for whatever motivation, such small groups of cores currently have
> >> the freedom to self-organize in a fairly emergent way and "champion"
> >> individual BPs that are important to them, simply by *independently*
> >> giving those BPs review attention.
> >>
> >> Whereas under the slots initiative, presumably this power would be
> >> subsumed by the "group will", as expressed by the prioritization
> >> applied to the holding pattern feeding the runways?
> >>
> >> I'm not saying this is good or bad, just pointing out a change that
> >> we should have our eyes open to.
> > 
> > Yeah, I'm really nervous about that aspect.
> > 
> > Say a contributor proposes a new feature, a couple of core reviewers
> > think it's important exciting enough for them to champion it but somehow
> > the 'group will' is that it's not a high enough priority for this
> > release, even if everyone agrees that it is actually cool and useful.
> > 
> > What does imposing that 'group will' on the two core reviewers and
> > contributor achieve? That the contributor and reviewers will happily
> > turn their attention to some of the higher priority work? Or we lose a
> > contributor and two reviewers because they feel disenfranchised?
> > Probably somewhere in the middle.
> > 
> > On the other hand, what happens if work proceeds ahead even if not
> > deemed a high priority? I don't think we can say that the contributor
> > and two core reviewers were distracted from higher priority work,
> > because blocking this work is probably unlikely to shift their focus in
> > a productive way. Perhaps other reviewers are distracted because they
> > feel the work needs more oversight than just the two core reviewers? It
> > places more of a burden on the gate?
> > 
> > I dunno ... the consequences of imposing group will worry me more than
> > the consequences of allowing small groups to self-organize like this.
> 
> Yes, this is by far my #1 concern with the plan.
> 
> I think perhaps some middle ground makes sense.
> 
> 1) Start doing a better job of generating a priority list, and
> identifying the highest priority items based on group will.
> 
> 2) Expect that reviewers use the priority list to influence their
> general review time.
> 
> 3) Don't actually block other things, should small groups self-organize
> and decide it's important enough to them, even if not to the group as a
> whole.
> 
> That sort of approach still sounds like an improvement to what we have
> today, which is alack of good priority communication to direct general
> review time.

A key thing for the priority list is that it is in a machine consumable
format we can query somehow - even if that's a simple static text file
in a CSV format or something. As long as I can automate fetching & parsing
to correlate priorities with gerrit query results in some manner, that's
the key from my POV.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|