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

Reply via email to