Open Stack

Each project is run in it's own way. We share some things but we all
operate in a different way at some level. For example, in Neutron, we've
moved away from waterfall design specs to an RFE process [1]. My point is
that, as John says, this is all a meritocracy, and it will be hard to push
from the top down uniformity in a lot of areas. Geoff, not sure that
answers your questions or not though, but hope it provides some perspective.

[1]
http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements

On Thu, Jun 4, 2015 at 9:44 AM, Geoff Arnold <geoff at geoffarnold.com> wrote:

> Man thanks, John. This is really useful.
>
> As you say, this describes what’s happening in Nova. Is there any
> pressure, process or impetus to adopt these ideas in the other projects? Is
> Nova “sui generis” because of scale, scope, or history? (I’m looping in
> Kyle in case he wants to provide a Neutron perspective.) I ask, because it
> is likely to significantly affect the way the Product WG has to operate if
> we have to interface with a wide range of project-specific governance
> models.
>
> Thanks again,
>
> Geoff
>
> > On Jun 4, 2015, at 3:09 AM, John Garbutt <john at johngarbutt.com> wrote:
> >
> > Hi,
> >
> > It was great to meet with a lot of you in that room at the summit.
> >
> > I just wanted to write down what I remember coming out of those
> > sessions. This email is very Nova focused, mostly because thats what I
> > am thinking about, but also because I think its a reasonable example
> > to start with, and I am keen to work with you all.
> >
> >
> > A)
> > Some interesting things around how to influence the developer community
> >
> > The development community is a meritocracy, this applies to non-devs
> > helping them, such as product managers.
> >
> > The PTLs have almost zero control on what people work on, although
> > they do get to block some things if there is a valid reason
> >
> > Its accepted that Product Managers are "hidden influencers" of what
> > the developers actually work on. Almost all our developers are
> > corporate sponsored professional developers, who are being allowed or
> > asked by their company to contribute to OpenStack.
> >
> > We frequently have developers talking about who their different use
> > cases are quite similar and collaborating to produce a single feature
> > that supports both sets of use cases. It would be good if some of
> > these frictions were discussed by product managers already. Currently
> > the developers proxy what their respective production managers want.
> > This seems crazy.
> >
> > There are lots of operator groups, user groups, and vendor groups. It
> > would be great to collect that feedback, and work out what projects
> > they need to talk to, and connect the special interest groups with the
> > appropriate projects in a productive way. As a carrot, you might find
> > some interesting customers as part of that discussion.
> >
> > We need the same for the API users, not just the deployers. But that
> > user group doesn't quite exist yet. The API-WG are doing some of that,
> > although mostly by proxy. If that group of users are not happy,
> > private cloud deployments will not get properly adopted, but that just
> > doesn't seem to be happening right now.
> >
> > Things like technical debt don't get all the attention they need,
> > partly as people are pushing specific features to get specific deals.
> > Someones people don't realise the ground work that is required to
> > support some of these features. Because you don't directly own the
> > code, its easy to assume its everyone else job, but thats just not
> > true, there is no magic army of people to fix those things.
> >
> > I think there were other things too, but I forget, and this email is
> > too long already.
> >
> >
> > B)
> > Some interesting specifics about OpenStack Dev Process
> >
> > 1) Specs are great at tracking features in a particular project
> >
> > You can see the nova template here, for more details on what we do.
> >
> http://specs.openstack.org/openstack/nova-specs/specs/liberty/template.html
> >
> > 2) Backlog specs help agree a problem statement with developers
> >
> > We are starting to use backlog specs to get agreement with the
> > developer community around a given problem statement. In general, this
> > is a partial spec.
> >
> > It was hoped we can use this to get feedback from the large operators
> > group, or similar to capture a problem, its use case and requirements,
> > so we can get developers to take a look at that, if its interesting to
> > them.
> >
> > We have not merged any nova ones yet, but here is the placeholder:
> > http://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html
> >
> > 3) Epics are useful, but not formally used right now.
> >
> > Epic = tracking specs that span multiple specs and multiple releases
> >
> > Nova has started a very informal method around this:
> > http://docs.openstack.org/developer/nova/devref/cells.html
> > http://docs.openstack.org/developer/nova/devref/upgrade.html
> >
> http://docs.openstack.org/developer/nova/devref/policy_enforcement.html#future-of-policy-enforcement
> >
> > We are in the process of sorting out devref, and I am likely to move
> > this into the nova-specs repo as something called an "Epics". But
> > thats a work in progress.
> >
> > I am likely to leave things that talk about the "architectural
> > evolution" of Nova in devref. Thats kind of something thats at a
> > higher level of abstraction to the Epics. Hopefully once we have some
> > examples that distinction will make more sense! (if not we can get rid
> > of that distinction).
> >
> > We don't tie back the Specs or Epics to your themes, like
> > Manageability, and Scalability, but I suspect that would be really
> > useful. I would except the developer writing the spec to do that
> > classification, not another team. Mostly because it seems its not very
> > obvious from reading the specs (I assume thats how the themes were
> > perviously mapped to projects and releases?)
> >
> > 4) We are OK at tracking/agreeing things that affect all projects
> >
> > Here are some things that affect all projects, and seem to work:
> >
> http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html
> > http://specs.openstack.org/openstack/api-wg/guidelines/http.html
> >
> > The TC owns the first. A horizontal team, the API-WG own the other.
> >
> > 5) We don't have anything for Epics that span multiple projects, but we
> need it
> >
> > Things tend to get driven only in one project, causing friction when
> > late in the release a request for urgent changes in another project
> > gets ignored. Help to track the cross project co-ordination would be
> > very welcome.
> >
> > Examples:
> > Cinder encryption, requires bits in Cinder and Nova
> > Keystone working on centralised policy
> >
> > This might be something that the Product Working Group could own. I
> > was thinking we could do something like this:
> > * email to the ML to each affect project to discuss the idea
> > * add backlog specs into relevant projects
> > * once those are approved, merge the cross project epic description
> > * then track the progress in each of the projects
> >
> >
> > But anyways, thats quite a big brain dump of things we spoke about.
> > Is that how others were remembering the discussion?
> >
> > Thanks,
> > John
> >
> > _______________________________________________
> > Product-wg mailing list
> > Product-wg at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>
>