<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 23, 2015 at 11:14 AM, Chris Dent <span dir="ltr"><<a href="mailto:chdent@redhat.com" target="_blank">chdent@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>One thing that I see as an indicator of quality is how a system fits together.  Does it feel like a well-designed cohesive unit or a collection of individually well-designed parts?  Current indications are that OpenStack feels to most people like a collection of parts.</div><div><br></div><div>I believe it is the TC's responsibility to facilitate and encourage the cross-project communication required to achieve a cohesive whole.  Work is already being done with this goal in mind, for example Thierry leads a weekly cross-project meeting for exactly this purpose, to facilitate communication between projects.  I do think he is wearing his Release Manager hat then, but that further illustrates that it is not the TC that need to be doing the work, but they should be setting the direction and expectations, and providing a framework within which to operate.</div><div><br></div><div>With all of the talk about the TC needing to 'get out of the way', I also believe that one of the responsibilities it has in technical leadership is to make some hard decisions when something is not working.  I know I sometimes have difficulty knowing when a project I am working on is going nowhere because I am too close to it.  I need someone with perspective to let me know what I can not see for myself.  To put it into the Big Tent metaphor, someone has to occasionally clean the elephant poo out of the tent.  Fortunately this has been a rare event so far in OpenStack's history, but the opening of the tent flaps changes that activity from an up-front one to an after-the-fact one and the TC must not forget that building a quality product is both including quality parts and assemblies, and removing the lesser quality ones.</div><div><br></div><div>As I said before, the majority of my time with OpenStack has been in cross-project activities and I get a first-hand taste of what people have to do to work with it.  It is not pretty.  There already are working groups addressing two of the most glaring inconsistent areas: APIs and log files.  The TC role here is to encourage and support these groups and prompt others to form where they will be able to do good work.  I have staked my future with OpenStack to two areas that both need this attention and I work every day to provide frameworks for developers and those wanting to do small-scale exercises, and for deployers and end-users who need to actually use an OpenStack cloud.  I think that the next level for that vision is strengthen that from within the TC itself.</div><div><br></div><div><br></div><div>dt</div><div><br></div></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>