Open Stack

> >  > 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.

Yeah, the outcome probably depends on the motivation/incentives that
are operating for individual contributors.

If their brief or primary interest was to land *specific* features,
then they may sit out the cycle, or just work away on their pet features
anyway "under the radar".

If, OTOH, they have more of a over-arching "make the project better"
goal, they may gladly (or reluctantly) apply themselves to the group-
defined goals.

However, human nature being what it is, I'd suspect that the energy
levels applied to self-selected goals may be higher in the average case.
Just a gut feeling on that, no hard data to back it up. 

> 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?

Well I think we have accept the reality that we can't force people to
work on stuff they don't want to, or entirely stop them working on the
stuff that they do.

So inevitably there will be some deviation from the shining path, as
set out in the "group will". Agreed that blocking this work from say
being proposed on gerrit won't necessarily have the desired outcome

(OK, it could stop the transitive distraction of other reviewers, and
remove the gate load, but won't restore the time spent working off-piste
by the contributor and two cores in your example)

> I dunno ... the consequences of imposing group will worry me more than
> the consequences of allowing small groups to self-organize like this.

Yep, this capacity for self-organization of informal groups with aligned
interests (as opposed to corporate affiliations) is, or at least should
be IMO, seen as one of the primary strengths of the open source model.

Cheers,
Eoghan