Open Stack

Chris, apologies for the late reply. No real excuse other than I wanted 
to hear what the other candidates had to say and listen a bit before I 
responded.

On 04/23/2015 12:14 PM, Chris Dent wrote:
> Here's the question:
>
> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?

Broad question :)

I think there's a couple things we (the TC) could do to improve the 
quality of OpenStack for developers:

= Focus on the public APIs =

No surprise here, but I'm a bit proponent of improving the consistency, 
usability, and documentation of our public APIs. I say "public APIs" 
because while I love the fact that the API working group has thus far 
focused on the RESTful APIs, I also think we should put some focus on 
non-RESTful APIs, like our notification message format, our RPC APIs 
(not currently public, but perhaps should be especially when things like 
the Nova scheduler are fully broken out).

The REST APIs are the first impression our community makes to our 
developer community. It should be a good impression. The guidance of the 
API working group should continue, and I think that we should also begin 
to produce recommendations for cleaning up the *existing* APIs of the 
OpenStack projects.

= Start a working group for building applications on top of OpenStack =

We have the "Win the Enterprise" working group. IMHO, we would do well 
to have a "Win the Future" working group that focuses on *modern* cloud 
application architecture and needs, and not legacy stuff.

Such a working group would be responsible for building a modern, 
distributed application reference that would use the various OpenStack 
APIs for infrastructure and platform management. It would showcase what 
can be done with and on OpenStack deployments.

And for operators of OpenStack, here's a couple ideas on things the TC 
could do to improve the quality of OpenStack for our operator community:

= Have a monthly "Feedback from Operators" conversation =

Dedicate part or all of one TC IRC meeting time per month to discuss 
operator feedback. Invite the operator community to come and tell us 
what has improved, what needs improving, and how the TC can find 
advocates in the contributor community to sponsor bugs and blueprints 
that operators need worked on.

= Develop a set of "operator:XXX" tags =

One big idea in the big tent initiative is to have more fine-grained 
tags that describe useful information to specific audiences. The TC can 
have a process (survey?) that gathers operator feedback on specific tags 
as they are applied to particular projects. For instance, we might work 
with the operator community to come up with a definition of a 
"operator:scales-to-100-nodes" (totally random example) that would apply 
to projects that the operator community verifies work at that particular 
scale. Have the operator community vote on whether various projects in 
the OpenStack code namespace have been deployed at that particular scale 
by the operator.

Anyway, those a just a few ideas. I'm looking forward to listening to 
new ideas from the newly elected TC members (regardless of whether I'm 
given the opportunity to be one of them ;)

Best,
-jay