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.gord...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
