Open Stack

> > 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.
> 
> I think that's because we've focussed in this discussion on the slots
> themselves, not the process of obtaining a slot.

That's fair.
 
> The proposal as it stands now is that we would have a public list of
> features that are ready to occupy a slot. That list would the ranked
> in order of priority to the project, and the next free slot goes to
> the top item on the list. The ordering of the list is determined by
> nova-core, based on their understanding of the importance of a given
> thing, as well as what they are hearing from our users.
> 
> So -- there's totally scope for lobbying, or for a subset of core to
> "champion" a feature to land, or for a company to explain why a given
> feature is very important to them.

Yeah, that's pretty much what I mean by the championing being subsumed
under the group will.

What's lost is not so much the ability to champion something, as the
freedom to do so in an independent/emergent way.

(Note that this is explicitly not verging into the retrospective veto
policy discussion on another thread[1], I'm totally assuming good faith
and good intent on the part of such champions)
 
> It sort of happens now -- there is a subset of core which cares more
> about xen than libvirt for example. We're just being more open about
> the process and setting expectations for our users. At the moment its
> very confusing as a user, there are hundreds of proposed features for
> Juno, nearly 100 of which have been accepted. However, we're kidding
> ourselves if we think we can land 100 blueprints in a release cycle.

Yeah, so I guess it would be worth drilling down into that user
confusion.

Are users confused because they don't understand the current nature
of the group dynamic, the unseen hand that causes some blueprints to
prosper while others fester seemingly unnoticed?

(for example, in the sense of not appreciating the emergent championing
done by say the core subset interested in libvirt)

Or are they confused in that they read some implicit contract or
commitment into the targeting of those 100 blueprints to a release
cycle?

(in sense of expecting that the core team will land all/most of those
100 target'd BPs within the cycle)

Cheers,
Eoghan 

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/042728.html

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