<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 10:14 AM, Chris Dent <span dir="ltr"><<a href="mailto:chdent@redhat.com" target="_blank">chdent@redhat.com</a>></span> wrote:<br><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What can and should the TC at large, and you specifically, do to ensure<br>
quality improves for the developers, end-users and operators of<br>
OpenStack as a full system, both as a project being developed and a<br>
product being used?</blockquote><div><br></div><div><br></div><div>Thank you for your question.</div><div><br></div><div>I think the largest hurdle for quality is a lack of a unified vision and direction for OpenStack. Without coordinated objectives for releases we have now 19+ projects driving in scattered directions. This effects quality on all levels. If we have a documented set of common release goals, we can better coordinate progress and deliver on the largest pain points for end-users and deployers. This was my hope for the Cross-Project Sessions at the summits, but it has not been realized. The TC should drive this coordination.</div><div><br></div><div>A growing ecosystem provides choice for deployers, but it also creates more questions and uncertainty. We need to provide some guidance to deployers as to what components are considered ready for production use and which pieces work complimentary together. The integrated release previously served that goal. We don't have a concrete plan moving forward to provide this guidance. To improve quality for deployers we need to make choosing which services to install simpler and the process to deploy and configure those services simpler. Additionally for horizontal projects rapid ecosystem growth creates a very difficult situation where either those horizontal projects attempt to provide that function for all, or leave it wide open which creates inconsistencies. This effects quality for end-users and deployers. The TC needs to stop hand-waiving here and concretely address the implications of this growth.</div><div><br></div><div>Improving the experience for developers means driving our ability to effectively scale the development process. Progress around excising tests from the coordinated gate begins to improve how well the gate works for individual projects. The other central component of this is scaling the review process. Too much frustration faces developers submitting specs and patches. The TC needs to push targeting less bureaucracy for developers and more toward allowing developers to contribute. </div><div><br></div><div>David</div></div></div></div>