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 :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev