Open Stack

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