tl;dr I'm concerned we're conflating user concerns and contributor
concerns. I'd like to see laser focus on two things that help both: 1)
Define layers in our governance and integration efforts 2) Pay down
technical debt with a focus on supporting users.

Great kick off Joe, thanks. I have been waiting to reply to this thread on
purpose while I try to gather as much info as I can about what both users
and contributors are interested in for our future. I have a pretty specific
curiosity about how we're framing this request: I see a spilt between
contributor concerns and user concerns.

Example contributor concerns:
scope definition
incubation and integration requirements
heavy-handed processes
review pileups
contributor license agreement concerns about preventing contributions and
technical debt weighing a project down

Example user concerns:
how do I know what's tested; what's buggy
how do I trust a part of OpenStack to put it into production and maintain
over time
why isn't there complete driver or hypervisor documentation for
security best practices
high availability across OpenStack
monitoring OpenStack
monitoring apps on my OpenStack infrastructure
my own users have needs; how can I get upstream to care about them

These example concerns are not comprehensive but I worry about conflation
causing us all to burnout and flail. I know we all work in the gray areas
but there's a black-and-white problem due to our current governance.

Since I write docs and work on technical committee concerns, I sit on a
cross-project and cross-concern bridge all the time, advocating,
prioritizing, standardizing, and weighing needs across many project teams.
The user concerns are a higher priority for docs currently, because they're
a support mechanism.

I think the Kilo cycle should be dedicated to:

 - Fulfill the promise of layers for defining OpenStack integration
gradients in governance and integration "taxes" such as consistency across
projects, reviews on projects with many drivers/contributors, infra, docs,
and testing
 - Pay down technical debt by sharply focusing on capabilities rather than
drivers that fulfill them

Two focus areas. Each of those will have a lot of work items. Both find
more common ground for devs and users. Let's do this!


On Wed, Sep 3, 2014 at 10:37 AM, Joe Gordon <> wrote:

> As you all know, there has recently been several very active discussions
> around how to improve assorted aspects of our development process. One idea
> that was brought up is to come up with a list of cycle goals/project
> priorities for Kilo [0].
> To that end, I would like to propose an exercise as discussed in the TC
> meeting yesterday [1]:
> Have anyone interested (especially TC members) come up with a list of what
> they think the project wide Kilo cycle goals should be and post them on
> this thread by end of day Wednesday, September 10th. After which time we
> can begin discussing the results.
> The goal of this exercise is to help us see if our individual world views
> align with the greater community, and to get the ball rolling on a larger
> discussion of where as a project we should be focusing more time.
> best,
> Joe Gordon
> [0]
> [1]
> _______________________________________________
> OpenStack-dev mailing list
OpenStack-dev mailing list

Reply via email to