Open Stack

confirmed


On Tue, Apr 21, 2015 at 4:02 PM, Angus Salkeld <asalkeld at mirantis.com> wrote:
> I'd like to announce my candidacy for the Technical Committee elections.
>
>
> This last (Kilo) cycle I have been the PTL for Heat, but will not be for
> Liberty.
>
> Because of this, if I get elected to the TC, I can dedicate a significant
> amount of time to TC duties.
>
> 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).
>
>
> Topics that I am interested in pursuing:
>
>
> 1. How can the TC/PTL's better influence what developers work on?
>
> 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?
>
> 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.
>
> 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
> TC supported "themes").
>
> A note on this (some motivation for taking advantage of stackalytics):
> It looks like this commit changed the default view on stackalytics from
> commits to reviews
> https://github.com/stackforge/stackalytics/commit/eb3bebbaa66a718e284d3095dfa8f496bb1d298c
> (14 Apr 2014)
> http://stackalytics.com/?release=all&metric=commits
> http://stackalytics.com/?release=all
>
> 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).
>
>
> 2. How can we better support new foundational projects that we expect other
> projects to consume.
>
> 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.
>
> 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?
>
> Could tenant-based services/endpoints be helpful in allowing end users to
> install optional projects?
>
>
> 3. Getting notification messages to the end user.
>
> Based on this:
> http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html
>
> 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.
>
>
> I'm interested in either leading or participating in working groups from
> within the TC to address these issues.
>
>
> Thanks
> Angus Salkeld
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2