On 08/13/2014 04:01 PM, Doug Hellmann wrote: > > On Aug 13, 2014, at 9:11 AM, Russell Bryant <rbry...@redhat.com> 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. >> >> -- >> Russell Bryant > > This is more formal than what we’ve been doing in Oslo, but it’s closer than > a strict slot-based approach. We talk about review priorities in the meeting > each week, and ask anyone in the meeting to suggest changes that need > attention. It’s up to the individual core reviewers to act on those > suggestions, though.
And I think that's a very healthy approach. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
