Open Stack

On Aug 13, 2014, at 9:11 AM, Russell Bryant <rbryant at 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.

Doug