Open Stack

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.

<more>
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
openness
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
<fill-in-the-blank>
logging
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!

 Anne

On Wed, Sep 3, 2014 at 10:37 AM, Joe Gordon <joe.gordon0 at gmail.com> 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]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/f2095eb1/attachment.html>