Open Stack

All - Good summary and discussion. Really appreciate the links to information. I will readup and send an update to this group.
Thanks
Carol

-----Original Message-----
From: Kyle Mestery [mailto:mestery at mestery.com] 
Sent: Thursday, June 04, 2015 8:07 AM
To: Geoff Arnold
Cc: product-wg at lists.openstack.org
Subject: Re: [Product] Throughts from the Product Working Group working sessions at the summit

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.htm
> l#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-guideli
> nes.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
>
>
_______________________________________________
Product-wg mailing list
Product-wg at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg