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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
