<div dir="ltr">I'd like to announce my candidacy for the Technical Committee elections.<br><br><br>This last (Kilo) cycle I have been the PTL for Heat, but will not be for Liberty.<br><br>Because of this, if I get elected to the TC, I can dedicate a significant amount of time to TC duties.<br><br>I have an interest in projects that exist in the upper layers in OpenStack (Heat, Murano, Mistral, Ceilometer/Monasca, Zaqar), so this gives me a slightly different viewpoint than the existing TC members (I hope this will be complementary).<br><br><br>Topics that I am interested in pursuing:<br><br><br>1. How can the TC/PTL's better influence what developers work on?<br><br>We currently have working groups and project tags, but are there other ways that we can encourage developers to work on global issues that users and operators are asking for?<br><br>So if the TC came up with say 2 global "themes" every cycle, let's say "ease of upgrades" and "scale", what can we use as a carrot to encourage a developer to work on these topics rather than something else. Clearly this has limits, but if the user survey is screaming "we need X", it would be great to have a tool to help focus developers onto this.<br><br>One idea might be to use stackalytics main page to show the work done on TC selected blueprints/bugs. We could tag particular blueprints/bugs and highlight the developers that have worked on these (i.e. can we use stackalytics as a tool to motivate developers to work on<div>TC supported "themes").<br><br>A note on this (some motivation for taking advantage of stackalytics):<br>It looks like this commit changed the default view on stackalytics from commits to reviews<br><a href="https://github.com/stackforge/stackalytics/commit/eb3bebbaa66a718e284d3095dfa8f496bb1d298c">https://github.com/stackforge/stackalytics/commit/eb3bebbaa66a718e284d3095dfa8f496bb1d298c</a> (14 Apr 2014)<br><a href="http://stackalytics.com/?release=all&metric=commits">http://stackalytics.com/?release=all&metric=commits</a><br><a href="http://stackalytics.com/?release=all">http://stackalytics.com/?release=all</a><br><br>See the sudden plateau of commits and increase in reviews after that time on the top graph (I am sure there are other factors at play too). <br><br><br>2. How can we better support new foundational projects that we expect other projects to consume.<br><br>Under the new big tent model, we are welcoming more projects into the openstack/ code namespace while simultaneously shifting the determination of production-worthiness to distributors and operators. This poses a problem for projects like Zaqar, Mistral, and even Heat, as these projects may be consumed/used by other upper-layer projects. Consuming projects end up with lots of conditional code as they must take into account that the deployed cloud may not have these dependent projects installed.<br><br>How can we make the end user (and inter-project) experience richer and friendlier with a consistent method of negotiating and discovering the underlying features a deployed cloud offers?<br><br>Could tenant-based services/endpoints be helpful in allowing end users to install optional projects?<br><br><br>3. Getting notification messages to the end user.<br><br>Based on this: <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html">http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html</a><br><br>Other clouds provide better messaging feedback on what the infrastructure is doing. We are really missing this and I'd like to help to get us to the point where the user (that doesn't have access to the logs) can understand what has happened to their resources.<br><br><br>I'm interested in either leading or participating in working groups from within the TC to address these issues.<br><br><br>Thanks<br>Angus Salkeld</div></div>