<div dir="ltr"><div>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.</div><div><br></div><div><more></div><div>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. </div><div><br></div><div>Example contributor concerns:</div><div>scope definition</div><div>incubation and integration requirements</div><div>heavy-handed processes</div><div>review pileups</div><div>contributor license agreement concerns about preventing contributions and openness</div><div>technical debt weighing a project down</div><div><br></div><div>Example user concerns:</div><div>how do I know what's tested; what's buggy</div><div>how do I trust a part of OpenStack to put it into production and maintain over time</div><div>why isn't there complete driver or hypervisor documentation for <fill-in-the-blank></div><div>logging</div><div>security best practices</div><div>high availability across OpenStack</div><div>monitoring OpenStack</div><div>monitoring apps on my OpenStack infrastructure</div><div>my own users have needs; how can I get upstream to care about them</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>I think the Kilo cycle should be dedicated to:</div><div><br></div><div> - 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</div><div> - Pay down technical debt by sharply focusing on capabilities rather than drivers that fulfill them</div><div> </div><div>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!</div><div><br></div><div> Anne</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 10:37 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>As you all know, there has recently been several very active discussions</div><div>around how to improve assorted aspects of our development process. One idea</div><div>that was brought up is to come up with a list of cycle goals/project</div>
<div>priorities for Kilo [0].</div><div><br></div><div>To that end, I would like to propose an exercise as discussed in the TC meeting yesterday [1]:</div><div>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.</div>
<div>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.</div>
<div><br></div><div><br></div><div>best,</div><div>Joe Gordon</div><div><br></div><div>[0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html</a></div>
<div>[1] <a href="http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html</a></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>